Belastungstests und Belastungsprofile

Kurze Zusammenfassung

Belastungstests sind ein systematischer Test der Leistung und Belastbarkeit unter realistischen und extremen Szenarien. Basis für den Erfolg: korrektes Verkehrsmodell (open vs closed), aufgezeichnete SLOs, reine Metrik (Latenz/Durchschlag/Fehler/Sättigung), repräsentative Daten, Automatisierung und Wiederholbarkeit. Das Ergebnis ist keine „RPS-Zahl“, sondern eine Lösung: Wo sind die Engpässe, wie viel kostet die Leistung, wo ist die Fehlerschwelle und wie kann sie verschoben werden.

SLO/SLI und Zielmetriken

SLO (Beispiel): p95 API ≤ 250 ms, p99 ≤ 600 ms; Fehler ≤ 0. 3 %/30 Tage.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Fehler-Bujets und Saturation-Trigger (z.B. CPU> 75% oder Queue-Tiefe> X → Degradation).

Arten von Tests

1. Baseline/Benchmark - Single Service/Endpoint, „ideale“ Konditionen.
2. Load ist ein realistischer „Arbeitstag“ + Ramp-up/Ramp-down.
3. Stress - Wir bauen die Last auf, um den Breakpoint zu degradieren und zu fixieren.
4. Spike ist ein scharfer Sprung (x2-x10 in Sekunden/Minuten).
5. Soak/Endurance - langer Lauf (8-72 h): Speicherlecks, Latenzdrift.
6. Kapazität - Eine abgestufte Last zum Erstellen einer Leistungskurve und zur Kapazitätsplanung.
7. Degradation/Chaos-mix - Last + Teilausfälle (verlangsamte DB, Cache-Drop, „kollabierte“ Aplink).

Verkehrsmodelle: Offen gegen Geschlossen

Open Model (realistischer für das Internet): Nutzer kommen mit einer Intensität von λ (Poisson-like-stream). Wenn das System bremst, häufen sich die Anfragen, anstatt „eingefroren“ zu werden.
Geschlossenes Modell: Feste Anzahl virtueller Benutzer (VU) mit think-time. Mit zunehmender Verzögerung sinkt der RPS künstlich ab - vorsichtig mit Schlussfolgerungen.
Empfehlung: Verwenden Sie für Front-End-APIs ein offenes Modell (k6 'Ankunftsrate'), für interne synchrone Skripte kombinieren Sie es mit einem geschlossenen.

Lastprofile (Muster)

„Normaler Tag“: Grundhintergrund + Tagesschwankungen.
„Peak-Event“: 10-30 Minuten vor dem Start (Aufwärmen), scharfer Spike am Start, Plateau, Schwanz.
„Turnier/Stream“: Stufenleiter, wiederholte Spitzen in Abständen.
„Infrastructure degradation“: Hälfte des Caches leer, eine Region ausgeschaltet, Erhöhung der PSP-Latenz.
„Failover“: der Verkehr fließt in 1-5 Minuten in die Reserve; Überprüfen Sie Auto-Scale/HPA/Retry-Stürme.

Umgebungsdaten und -vorbereitung

Testdaten: realistische Kardinalität (Anbieter, Währungen, Länder), „schmutzige“ Felder, Anfrageverteilungen (Pareto/Zipf).
Secrets/PII: Anonymisierung; Schlüssel/PSP - Sandbox.
Umgebung: dedizierter Perf-Stand, Isolation von Integrationen (Mock/Stacks), feste Versionen.
Beobachtbarkeit: Metriken (Prometheus), Protokolle (Loki/ELK), Tracks (OTel). Notieren Sie die Build-ID in den Antworten.

Anti-Shtorma-Retrays und Idempotenz

Retrai nur für idempotente Operationen; Setzen Sie ein Retry-Budget (z. B. ≤ 10% des Datenverkehrs).
Exponential backoff + jitter; „collapsing“ von identischen GETs.
Für Zahlungen gibt es idempotente Schlüssel und explizite Status.
Schutz vor Thundering-Herd: Cashlocks, SWR, lokale Semaphoren.

Werkzeuge und Muster

k6 (Skript, Open-Modell, gute Berichterstattung), Locust (Python-Skripte), Gatling (Scala), JMeter (eine breite Palette von Protokollen).
Protokoll: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; Server-Push nicht „als GET“ testen.
Verkehrserzeugung: horizontale Skalierung der Generatoren, Kontrolle des Netzwerkengpasses.
Profilaufnahme: pprof/async-profiler/ebpf unter Last, OTel-Tracks.

Mini-Beispiel k6 (open-model + spike):

javascript import http from 'k6/http';
import {check, sleep} from 'k6';

export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};

export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}

Vorgehensweise

1. Hypothese → welche Engpässe wahrscheinlich sind (CPU, DB, Cache, Netzwerk, TLS, GC).
2. Profil → Szenarien/Routen, Verkehrsanteile, Modelle (offen/geschlossen), Daten.
3. Aufwärmen → Cache/Connects/TLS/Interpreter.
4. Erhöhung der → Stufe auf die Zielintensität.
5. Das Plateau → eine Sammlung von stabilen Metriken und Spuren.
6. Stress/Rückgang → Suche nach dem Bruchpunkt, Beobachtung des Auto-Skale.
7. Analyse → Korrelation von Metriken, Flamegraph, Bericht und Änderungsplan.
8. Die Wiederholung → über die CI-Pipeline (Regression Perf).

Analyse der Ergebnisse

Kurve „Last → Verzögerung/Fehler“: Wir suchen nach dem Knie (Kapazität).
Latenzausbruch: Netzwerk (DNS/TLS/connect), Proxy, Anwendung, DB, externe Anrufe.
Sättigung: CPU> 75-85%, GC-Pause> p95, I/O-Erwartungen, Aufgabenwarteschlange.
Elastizität: Reaktionszeit des Autoscales (HPA/KEDA), „Kaltstart“, Aufwärmen des Caches.
Kosten: $/1000 RPS bei Ziel-SLO, Budgetprognose für die Spitze.

Ingenieurpraktiken

Indikatoren der Degradation: „Schwänze“ p99, Anstieg der Warteschlangen, Rückgang der Trefferquote, Anstieg der Retrayversuche.
Confounder ausschließen: Dateideskriptor-Limits, sysctl, conn-pool, 'reuseport', TLS-Ketten, OCSP.
DB: Indizes/Pläne/Abfrage-Cache, Verbindungspool, Batch-Operationen, Backpressure auf Producer.
Caches: Größe/eviction-Politik, Hot Keys, Replikation.
Netzwerk/edge: HTTP/2/3, resumption≥70%, Brotli, CDN-Cache-Schlüssel, tiered-cache.

Beobachtbarkeit unter Last

Metriken: System (CPU/mem/IO), Laufzeit (GC/heap), Netzwerk (RTT/loss/ECN), L7 (p95/99, 5xx/429), Warteschlangen, DB/Cache-Cluster.
Traces: Sampling auf „tail-based“, Build-id/Kanarienvogel-Markierungen.
Logs: Aggregation von Fehlern mit Volumenbegrenzung (also nicht „hinterDOSoder“ Log-Pipeline).
Experimente: Feature-Flags und Configs müssen in einem Bericht festgehalten werden.

Automatisierung und CI/CD

Perf-Jobs in CI (Rauch 3-5 min, nightly 30-60 min, wöchentlich soak).
Toleranzgrenzen: Latenz/Fehler/Ressourcen → „Build-Break“ in der Regression.
Artefakte: Grafiken, Flamegraphen, Profile, JSON-Berichte (k6/jtl).
Versionierung von Daten und Skripten, PR-Revue von Perf-Skripten.

Spezifität für iGaming/Fintech

Turniere/Matches: spike + plateau; TLS/DNS/CDN-Warming, erhöhte Pool-Limits, „graue“ Routen für Bots.
Zahlungen/PSP: Sandbox-Limits, Idempotenz, strikte Timeouts; Überprüfung des Degrade-Modus (Verzeichnis-Cache, Warteschlangen).
Jackpots/Events: Atomarität und Konsistenz, keine Takes, Belastung der RNGs/Leaderboards.
Betrugsbekämpfung/AML: Regelbelastung/ML-Scoring, Backpress, Ereignisdeduplizierung.
Regulatory: Protokollierung von Metriken und Versionen bei Peaks, Berichte für Audits.

Start-Checkliste

SLO/SLI und „rote Linien“ (Fehler/Latenz/Sättigung) sind festgelegt.
Lastskripts und Profile genehmigt (offen/geschlossen, spike/soak/stress).
Daten sind realistisch, PII maskiert, Integrationen sind sandbox/mock.
Beobachtbarkeit bereit: Metriken/Traces/Logs, Release-Tags.
Systemkonfigs (ulimit/sysctl/pools) werden dokumentiert.
Auto-Scale/Cache-Heizung Plan und Rollback-Kriterien.
Schwellenalarme und Befehlskommunikationsplan (On-Call).
Berichtsvorlage (Grafiken, Schlussfolgerungen, Aktionen) erstellt.

Typische Fehler

Der Closed-Model-Test liefert ein „grünes“ Ergebnis und der Prod fällt ab (das Open-Model kann nicht ignoriert werden).
Nicht repräsentative Daten (eine Währung/ein Anbieter) → falsche Schlussfolgerungen.
Null Vorbereitung: Kalte Caches/TLS/Anschlüsse → überhöhte Latenz am Start.
Grenzenlose Retrays → Stürme und kaskadierende Stürze.
Identische Profile für alle Dienste → Überspringen echter „Hotspots“.
Das Fehlen von Soak-Runs → Speicherlecks und Drifts ist nicht sichtbar.
Undurchsichtige Ergebnisse: Es gibt keine Spuren/Flamgraphen → es ist unmöglich, den Engpass zu lokalisieren.

Mini-Playbooks

Definieren der Bandbreitengrenze (Breakpoint)

1. Schritte von 10-20% der Last alle 5-10 min. 2) Wir erfassen den Moment, in dem p95 stark ansteigt und Fehler> SLO. 3) Entfernen Sie die CPU/DB/Cache-Profile. 4) Optimierungsplan und Wiederholung.

Rückzugsstürme eindämmen

1. Retry-Budget einschränken und Backoff + Jitter aktivieren. 2) Geben Sie request-collapsing/SWR ein. 3) Erlauben Sie den „Degrad-Modus“ (eingeschränkte Funktionalität). 4) Überprüfen Sie die Idempotenz.

Peak Event (Turnier) - Vorplan

1. CDN/DNS/TLS/Pools aufwärmen. 2) Erhöhen Sie HPA-Ziel, bereiten Sie Reserve vor. 3) Separate Rate Limits für Bots. 4) „Pik-Modus“ Dashboards, On-Call-Kommunikationsbrücke.

Soak-Nacht

1. 8-12 Stunden stabile Belastung. 2) Wir überwachen heap/FD/conn/GC-Pausen. 3) Wir vergleichen Delta p95 und Hit-Ratio. 4) Wir reparieren Leckagen und Drift.

Ergebnis

Belastungstests sind ein technischer Entscheidungsprozess und kein „Rennen um RPS“. Modellieren Sie reale Profile (insbesondere das offene Modell), erfassen Sie SLOs, nehmen Sie Metriken und Spuren auf, suchen Sie nach dem Performance-Knie und zählen Sie die Performance-Kosten. Automatisieren Sie Läufe, halten Sie Anti-Sturm-Retrays und planen Sie Spitzenereignisse - damit die Plattform in den stressigsten Momenten vorhersehbar und stabil ist.