Belastungs- und Stresstest
1) Begriffe und Ziele
Belastungstest - Prüfung im Arbeitsbereich (Ziel RPS/Wettbewerbsfähigkeit) gegen SLO (z.B. p95 <200 ms, Fehlerrate <0. 5%).
Stresstest - Überschreiten (vor/über der Sättigung von CPU/DB/Netzwerk), Beobachtung von Degradation und Wiederherstellungsmechanik.
Spike-Test - plötzliche Lastspitzen (× N innerhalb von Minuten).
Soak/Endurance ist ein langer Lauf (Stunden/Tag), um nach Lecks, GC-Drift, Fragmentierung, Warteschlangen zu suchen.
Kapazitätstest - Berechnet das Plateau von Durchsatz (Sättigungspunkt) und Bestand.
Ziele: SLO bestätigen, Plateau fixieren, Engpässe verstehen, Auto-Skalierung und Limits kalibrieren.
2) Verkehrsmodell: offen vs geschlossen
Geschlossenes Modell (concurrency-driven): Eine feste Anzahl von virtuellen Benutzern (VUs), von denen jeder nach der Antwort think time macht.
Open Model (Arrival-Rate): Feste Anforderungseingangsintensität (RPS), unabhängig von den Antworten.
Little’s Law: `L = λ W`
„L“ die durchschnittliche Anzahl der gleichzeitig bedienten Anfragen,
„λ“ - Intensität (RPS),
'W' ist die durchschnittliche Antwortzeit.
Daher die Einschätzung der notwendigen Wettbewerbsfähigkeit des Generators: "concurrency ≈ target_RPS p95_latency'.
3) Metriken: Was wir messen
SLI Verzögerungen: p50/p90/p95/p99 und Schwanz p99. 9; getrennt für „heiße“ und „kalte“ Wege.
Fehler: '5xx', '4xx' (gültig/nicht gültig), timeouts, aborted.
Bandbreite: Steady RPS, throughput Threads/Bytes.
Ressourcen: CPU, RAM/Heap, GC Pausen, Disk IOPS/lat, Netzwerk Bandbreite, Anzahl der Verbindungen/FD.
Warteschlangen und Backpresher: Tiefe, Wartezeit, Anzahl der Shed/Limited Requests.
Cache-Effizienz: Hit/Miss, Aufwärmstürme.
DB/Caches/Queues: p95 Anfragen, Sperren, Konflikte, Pool-Utilization.
4) Stände und Daten
Konfigurationsäquivalenz: Softwareversionen, Limits (uLimit, conntrack), JVM/GC Configuration, Pool 's.
Topologie: LBs, CDN, WAF, TLS, die gleichen Netzwerk „Hops“.
Daten: realistische Verteilungen (Objektgrößen, „heiße „/“ kalte “Schlüssel, Regionalität).
Kalt-/Warm-/Warmstart: einzelne Läufe; Achten Sie darauf, „kalte“ Caches zu testen.
Hintergrundisolierung: Deaktivieren Sie irrelevante Jobs/Kronome oder berücksichtigen Sie deren Wirkung.
5) Szenarien (Lastprofile)
1. Baseline: Schrittweises Übertakten auf Ziel-RPS, 10-30 min halten.
2. Ramp & Hold: sanftes Wachstum bis zu X% über dem Ziel, Retention → Tail-Analyse.
3. Spike: sofortige × 2- × 5-Spitze für 1-5 Minuten, dann Rückkehr.
4. Stress to Failure: Schritte bis zum Ausfall; Wir fixieren den ersten Punkt der Nichterfüllung von SLO und den Punkt des „Abbruchs“.
5. Soak: 6-24h mit Verkehrsvariabilität (Tag/Nacht), Follow-up der Likes/Drift.
6. Mixed: Mischung der Endpunkte nach Realverteilung (Zipf/Pareto), unterschiedliche Gewichte.
6) Schritt-für-Schritt-Prozess
Definieren Sie SLOs und Zielverkehrsprofile.
Wählen Sie ein Lastmodell (offen/geschlossen), legen Sie die Ankunftsrate oder die VUs fest.
Bereiten Sie Daten und „heiße „/“ kalte “Modi vor.
Einrichten der Telemetrie (Traces/Metriken/Logs), Korrelation mit der Testwunde.
Aufwärmen und Laufen, Sammeln von Artefakten (CPU/Heap Profile, Flame Graphs, Explain/Slow-Logs DB).
Analyse von Engpässen, Bildung von Aktionselementen.
Reprogon nach Fixes, Bazline Update und Capacity Playbook.
7) Engpässe und typische Fixierungen
CPU-gebundener Service: Profilierung → Beseitigung heißer Funktionen, Allokation, Verzweigung; Vektorisierung, Cache-freundliche Struktur.
Netzwerk/TLS: Keep-Alive, HTTP/2/3, Connection-Pooling, korrekte Timeouts, Verringerung der Chat-Fähigkeit.
DB: Indizes, Batchings, vorbereitete Abfragen, Konnektivitätspool, R/W-Split, Ergebniscaching, Deduplizierung von Abfragen.
Caches: Größe, TTL, Anforderung Coalescing, Sturmschutz, Warming, regionale Bälle.
Warteschlangen/Broker: Grenzen der Akzeptanz/Parallelität, Größe der Schlachtfelder, idempotent Verbraucher, DLQ-Decken.
Garbatage/Pausen: GC Tuning, Puffer mieten, Objektpooling in vernünftigen Grenzen.
I/O/Disk: asynchrone Eingabe/Ausgabe, Kompression, Komprimierung von Antworten mit angemessenem Niveau.
8) Grenzen und Schutz
Budget-Timeouts: von oben nach unten, um Kaskaden zu vermeiden.
Rate limit/token-bakets: vorhersehbare Degradation statt „langer Tod“.
Circuit Breaker und Shading mit niedriger Priorität bei Sättigung.
Backpressure: Signale und Begrenzung der Parallelität tief in der Kette.
Bulkheads: Isolierung von Pools für kritische Endpunkte.
Idempotency: Schlüssel für sichere Wiederholungen unter Retrays.
9) Werkzeuge und wann man sie wählt
k6 ist eine prägnante JS, ausgezeichnete Unterstützung für Ankunftsrate, Integration und Graphen.
Gatling - Scala DSL, ein Hochleistungsgenerator.
JMeter - ein flexibles, reiches Ökosystem; praktisch für Protokolle/Plugins.
Locust - Python-Skripte, praktisch für die komplexe Logik von benutzerdefinierten Flows.
Vegeta/hey/wrk - Mikrobenci und Punktläufe auf HTTP.
tc/netem, toxiproxy - Injektion von Netzwerkdegradationen.
Flamegraph/profiler - Suche nach CPU/heap „hot spots“.
10) Beispiele (Skizzen)
k6 (offenes Modell, Endpunkt-Mix)
javascript import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};
export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}Gatling (Stufen und Spike)
scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))Lastplan (YAML-Skelett)
yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m11) Automatisierung und Lebenszyklus
Perf-Rauch in jeder PR (kurzer Lauf der wichtigsten Endpunkte).
Nächtliche „Capacity“ -Läufe auf einem Stapel mit Berichten und Profilartefakten.
Gates in CI/CD: Failbilde bei Regression p95/p99> X% der Bazline oder Wachstum der Fehlerrate.
Bazline-Versionierung und Speicherung von Profilen/Flamgraphen als Artefakte.
Relevanztags: Welcher Dienst/Endpunkt wird abgedeckt, welches Verkehrsprofil wird genutzt.
12) Anti-Muster
Der Generator und der getestete Service auf einer Maschine → verzerrte Ergebnisse.
Nur ein geschlossenes Modell (VUs) für API-Backs → eine Untererfassung der Tails und eine Fehleinschätzung.
Läufe über leere DB/Cache ohne Kaltstart.
Keine realistischen Verteilungen (alle Abfragen sind gleich).
Keine Telemetrie (nur RPS/Latenz auf der Generatorseite).
Vergleich ohne stabile Baslines und Umgebungskontrolle.
„Optimierung“ durch erhöhten Timeout statt Korrektur der Ursache.
13) Checkliste des Architekten
1. SLO und Typen-/Spitzenlast definiert?
2. Richtiges Modell ausgewählt (offen/geschlossen) und Verkehrsprofil gemalt?
3. Der Stand ist gleichwertig in Bezug auf Configs und Topologie, gibt es einen kalten/heißen Modus?
4. Telemetrie und Profile inklusive, Prüfwundmarkierungen angebracht?
5. Läufe: baseline/ramp/spike/stress/soak - abgedeckt?
6. Sättigungspunkte werden erfasst und die Versorgung geplant (Safety Margin)?
7. Limits, Breaker, Backprescher, Idempotency, Shading Policen sind gesetzt?
8. Gibt es CI-Gates auf p95/p99 Regression und Fehlerrate, Bazlines versioniert?
9. Nach den Fixes - Reprogon und Playbook-Update nach Leistung?
10. Ist der Plan der Auto-Skalierung und der Notfallmodi dokumentiert?
Schluss
Belastungs- und Stresstests sind keine einmaligen „Rennen“, sondern kontinuierliche Engineering-Praxis. Ein realistisches Verkehrsmodell, korrekte Stände, Telemetrie und Automatisierung in CI/CD verwandeln die Leistung von der „geheimen Magie“ in eine metrikgetriebene Fähigkeit: Sie wissen, wo Ihre Decke ist, wie sicher der Bestand ist und welche Änderungen die Benutzererfahrung wirklich verbessern.