Belastungstests und Stress

Belastungstests und Stress

1) Warum es notwendig ist

• Bestätigen Sie die Kapazität (wie viele RPS/Wettbewerbssitzungen das System bei einem bestimmten SLO aushalten kann).
• Finde Flaschenhalse (CPU/IO/DB/Netzwerke/Sperren/Pools).
• Konfigurieren Sie Performance-Budgets und „Gates“ in CI/CD.
• Reduzieren Sie das Risiko von Releases (p95/p99-Regressionen, Anstieg der Fehler beim Peak).
• Planen Sie Kapazität/Kosten (Scale-out und Reserven).

2) Arten von Perf-Tests

Last (Arbeitslast): realistischer Verkehr in der Nähe von Spitzen; Validierung von SLO.
Stress (stress): das Wachstum bis zu/über die Grenze → das Verhalten beim Abbau, wo es bricht.
Spike (Impuls): schneller Lastsprung → Elastizität/Autoscale.
Soak/Endurance: Stunden/Tag → Lecks, Fragmentierung, Latenzdrift.
Capacity/Scalability: wie sich throughput/latency beim Scale-out ändert; Gesetz von Amdal/Gustafson.
Rauch perf: kurzer „Rauch“ -Lauf bei jeder Veröffentlichung (Performance Sanity).

3) Verkehrserzeugungsmodelle

Geschlossenes Modell (fixed VUs/concurrency):'N 'Benutzer, jeder macht Anfragen → Warteschlange im Client. Gefahr, Überlastung zu verbergen.
Das offene Modell (arrival rate): der Strom der Anträge mit der Intensität der λ (req/s), wie im realen Leben. Korrekter für öffentliche APIs.

Little's Law: „L = λ × W“.
Für Pool/Service: Mindestparallelität ≈ 'λ × W' (20-50% des Bestands hinzufügen).
Wo 'λ' ist, ist throughput,'W 'ist die durchschnittliche Wartungszeit.

4) Lastprofile und Szenarien

User Journey Mix: Anteile der Skripte (Login, Browse, Deposit, Checkout...).
Think-time: Pausen des Benutzers (Verteilungen: exponentiell/lognormal).
Datenprofil: Größe der Antworten, Payload, Variabilität der Parameter.
Korrelation: Verknüpfen Sie die Schritte (Cookies/Token/ID) wie in einem echten Flow.
Kalt/warm/heiß Cache: separate Läufe.
Read vs Write: Balance von Lesungen/Einträgen, Idempotenz für Retrays.
Multi-Region: RTT, Verteilung nach POP/ASN.

5) Testumgebung

Isolierung: Der Stand ist in Bezug auf Topologie/Einstellungen nahe am Markt (aber wir „schlagen“ den Prod nicht).
Daten: PII-Maskierung, Volumen, Indizes wie in der Produktion.
Lastgeneratoren: nicht gegen CPU/Netzwerk stoßen; verteilte Läufer, Zeitsynchronisation.
Beobachtbarkeit: Metriken/Traces/Logs, Synthetik am Perimeter, Export von CPU/Heap-Profilen.

6) Metriken und SLI

Durchlauf: RPS/Transaktionen pro Sekunde.
Latency: p50/p95/p99, TTFB, server time vs network.
Fehler: Anteil von 5xx/4xx/Domänenfehler.
Sättigung: CPU, Last avg, GC, Laufwerk IOps/Latenz, Netzwerk, Pool warten.
Business SLI: Erfolg der Einzahlung ≤ 5s, Auftragsbestätigung ≤ 2s.

Nehmen Sie die Schwellenwerte aus dem SLO (z.B. "99. 95% ≤ 300 ms"), Burn-Rate während des Laufs überwachen.

7) Suche nach Engpässen (Methodik)

1. Wärmen Sie das System stabil auf 60-80% der Ziellast auf.
2. Erhöhen Sie die Schritte (ramp) → notieren Sie, wo p95/p99 und error-rate wachsen.

• Warteschlangen in Pools (DB/HTTP),
• Wachstum der WAIT/Locks (DB),
• GC-Pausen/Heap,
• Netzwerk retransmits/Paketverlust,
• Festplattenlatenz/Cache-Fehler.
• 4. Lokalisieren: binäre Suche im Abfragepfad, Profiler (CPU/alloc/lock-profile).
• 5. Fixieren Sie die „Flasche“ → Tuning → wiederholen Sie den Lauf.

8) Verhalten unter Stress

Graceful degradation: Limits, Circuit-Breakers, Warteschlangen mit Backpress, Modus „in Bearbeitung genommen“.
Retrays: maximal 1, nur idempotent; jitter; Das Retraybudget ≤ 10% des RPS.
Fail-open/Fail-closed: Bei nicht-kritischen Abhängigkeiten Fail-open (Cache/Stubs) zulassen.
Cascading failure: Isolierung von Pools/Quoten (Bulkhead), schnelle Timeouts, „glatte“ Abschaltung von Funktionen (Feature Flags).

9) Werkzeuge (Auswahl nach Aufgabe)

k6 (JavaScript, open/open-model, schnell, praktisch in CI).
JMeter (reich an Ökosystem, GUI/CLI, Plugins, aber schwerer).
Gatling (Scala DSL, hohe Leistung).
Locust (Python, Skriptflexibilität).
Vegeta/hey/wrk (Mikro-Benchmarks und Schnellcheck).

Die Regel: ein „Kern“ -Tool + ein leichter CLI für Rauchperf in PR.

10) Beispiele (Snippets)

10. 1 k6 (offenes Modell mit Ankunftsrate)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (Profilidee)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertions nach Zeit/Code.

10. 3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) Daten, Korrelation, Vorbereitung

Seed-Daten: Kataloge, Nutzer, Bilanzen, Token - wie im Angebot.
PII Maskierung/Anonymisierung; Erzeugung von Synthetik über reale Verteilungen.
Korrelation: Extrahieren Sie IDs/Token aus den Antworten (RegExp/JSONPath) und verwenden Sie sie in den nächsten Schritten.

12) Beobachtbarkeit während der Läufe

RED-Dashboards (Rate, Errors, Duration) entlang der Routen.
Beispiele: Übergang von Metriken zu Tracks (trace_id).
Fehlerprotokolle: Sampling + Aggregation, Duplikate/Idempotenz.
System: CPU/GC/Heap, Laufwerke/Netzwerk, Pool warten.
DB: Top-Anfragen, Sperren, Index-Scans, Bloat.

13) Automatisierung und Performance-Gates

CI: kurze Läufe pro Merge (z.B. k6 2-3 Minuten) mit Schwellen.
Nightly/Weekly: lange Soak/Stress in einer separaten Umgebung; Berichte und Trends.
Kanarische Releases: Analyse der SLO (error-rate, p95) als „Tor“ der Promotion.
Regressionen: baseline vs current build; Warnmeldungen bei Verschlechterung> X%.

14) Kapazitätsplanung und Kosten

Kurven throughput→latency: Bestimmen Sie den Kniepunkt (Knie) - danach wächst p99 stark.
Scale-out: Messen Sie die Skalierungseffizienz (RPS-Delta/Knoten-Delta).
Kosten: „RPS pro $/Stunde“, Reserve für Spitzenereignisse + DR-Reserve.

15) Anti-Muster

Schlagen Sie den Prod ohne Kontrolle oder testen Sie ihn in einer „leeren“ Umgebung, die nicht wie Prod aussieht.
Geschlossenes Modell mit festen VUs, die Überlastung verbergen.
Das Fehlen von Think-Time/Daten → unrealistische Cache-Hits oder umgekehrt - Sturm auf die Quellen.
Ein Skript „/ping “anstelle eines benutzerdefinierten Flows.
Fehlende Beobachtbarkeit: „Wir sehen nur RPS und durchschnittliche Latenz“.
Unkontrollierte Retrays → Selbst-DDoS.
Mischen Sie Test und Optimierungen, ohne Hypothesen/Änderungen zu fixieren.

16) Checkliste (0-30 Tage)

0-7 Tage

Definieren Sie SLI/SLO und Zielverkehrsprofile (Mix, Think-Time, Daten).
Werkzeug auswählen (k6/JMeter/Locust), Dashboards RED anheben.
Stand- und Saatgutdaten vorbereiten, Limits/Captchas von Drittanbietern deaktivieren.

8-20 Tage

Erstellen Sie Szenarien: Open-Model (Ankunftsrate), Cold/Warm/Hot Cache.
Starten Sie load → stress → spike. Kniepunkt und Engpässe fixieren.
Implementieren Sie Performance Gates im CI (Micro Run).

21-30 Tage

Soak-Test 4-24 h: GC-Lecks/Drift, Stabilisierung.
Dokumentieren Sie Grenzen, Kapazitätsplan, Illustrationen „RPS→p95/oshibki“.
Bereiten Sie das Runbook „wie man Limits/Scale erhöht“ und „wie man degradiert“ vor.

17) Reifegradkennzahlen

Es gibt realistische Profile (Mix, Think-Time, Daten), die ≥ 80% des Datenverkehrs abdecken.
RED-Dashboards + Trace sind für alle Tests verbunden.
Performance Gates blockieren Releases bei p95/error regression.
Die Kapazität und der Kniepunkt werden nach Schlüsseldiensten dokumentiert.
Monatliche Soak/Stress-Läufe und Dynamikberichte.
Die Resistenz gegen „Spike“ wird durch Auto-Scale und das Fehlen von Cascade-Fail bestätigt.

18) Schlussfolgerung

Belastungstests sind eine regelmäßige technische Praxis und keine einmalige „Messung“. Simulieren Sie echte Benutzer (Open-Model), messen Sie, was das Kundenerlebnis (SLI/SLO) widerspiegelt, halten Sie Beobachtbarkeit und „Gates“ in CI/CD, führen Sie Stress/Spike/Soak-Runs durch und fixieren Sie den Kniepunkt. Dann werden Peak Events und Black Swans zu überschaubaren Szenarien und die Performance zu einem vorhersagbaren und messbaren Parameter Ihrer Plattform.