Testarea sarcinii și a stresului

1) Termeni și obiective

Test de încărcare - test în intervalul de lucru (țintă RPS/concurență) împotriva SLO (de exemplu, p95 <200 ms, rata de eroare <0. 5%).
Testul de stres - merge dincolo (înainte/peste saturația CPU/DB/rețea), observând degradarea și mecanica de recuperare.
Testul Spike - explozii ascuțite de sarcină (× N timp de minute).
Înmuiere/Rezistență - termen lung (ore/zi) pentru a găsi scurgeri, derivă GC, fragmentare, creșterea cozii.
Încercarea de capacitate - calcularea platoului de debit (punct de saturație) și a rezervelor.

Obiective: confirmați SLO, fixați platoul, înțelegeți blocajele, calibrați scalarea automată și limitele.

2) Modelul de trafic: deschis vs închis

Model închis (bazat pe concurență): un număr fix de utilizatori virtuali (VU), fiecare după răspunsul face timp de gândire.
Model deschis (rata de sosire): rată fixă de solicitări (SPR), indiferent de răspunsuri.

Legea lui Little: 'L = λ W'

„L” este numărul mediu de cereri deservite simultan,

„λ” - intensitate (SPR),

„W” este timpul mediu de răspuns.
Prin urmare, evaluarea competitivității necesare a generatorului: "concurență ≈ target_RPS p95_latency'.

3) Metrics: ceea ce măsurăm

Întârziere SLI: p50/p90/p95/p99 și coada p99. 9; separate pentru căi „fierbinți” și „reci”.
Erori: '5xx', '4xx' (valid/nevalid), timeout, avortat.
Debit: SPR susținut, fluxuri de debit/octeți.
Resurse: CPU, RAM/heap, pauze GC, IOPS/lat disc, lățime de bandă de rețea, număr de conexiuni/FD.
Cozi și Backprescher: adâncime, timp de așteptare, număr de solicitări limitate/vărsat.
Eficiență cache: lovit/dor, furtuni de încălzire.
DB/cache/cozi: cereri p95, încuietori, conflicte, utilizarea piscinei.

4) Standuri și date

Echivalență de configurare: versiuni software, limite (uLimit, conntrack), JVM/GC config, piscine.
Topologie: LBs, CDN, WAF, TLS, aceeași rețea „hamei”.
Date: distribuții realiste (dimensiuni ale obiectelor, chei „fierbinți „/” reci „, regionalitate).
Pornire rece/caldă/fierbinte: alergări individuale; Asigurați-vă că pentru a testa „rece” cache.
Izolarea de fond: dezactivați locurile de muncă/cronomele irelevante sau luați în considerare efectul acestora.

5) Scenarii (profiluri de sarcină)

1. Valoarea iniţială: accelerarea treptată la ţinta SPR, menţineţi 10-30 min.
2. Rampa & Hold: creștere lină la X% peste țintă, retenție → analiză coadă.
3. Spike: instant × 2- × 5 stropi timp de 1-5 minute, apoi reveniți.
4. Stresul la eșec: pași către eșecuri; fixați primul punct de eșec SLO și punctul „break”.
5. Înmuiere: 6-24 ore cu variabilitatea traficului (zi/noapte), ceas pentru fețe/derivă.
6. Amestecat: amestec de criterii finale prin distribuție reală (Zipf/pareto), greutăți diferite.

6) Proces pas cu pas

Definiți profilurile de trafic SLO și țintă.
Selectați modelul de încărcare (deschis/închis), setați rata de sosire sau VU.
Pregătiți datele și modurile „fierbinți „/” reci „.
Configurarea telemetriei (trasee/metrici/busteni), corelarea cu rularea testului.
Încălzirea și funcționarea, colectarea artefactelor (profile CPU/heap, grafice flacără, explica/lent-busteni DB).
Analiza blocajului, formarea elementelor de acțiune.
Reprogon după remedieri, actualizare de bază și playbook capacitate.

7) Blocaje și remedieri tipice

Serviciul CPU-bound: profilare → eliminarea funcțiilor fierbinți, alocări, sucursale; vectorizare, structura cache-friendly.
Rețea/TLS: păstrați-în viață, HTTP/2/3, conexiune pooling, timeout corecte, chat redus.
DB: indici, batching, interogări pregătite, piscină de conexiune, separare R/W, cache rezultat, interogare de eliminare a duplicatelor.
Cache: dimensiune, TTL, cerere coalescing, furtună de protecţie, încălzire, bile regionale.
Cozi/brokeri: limite de acceptare/paralelism, dimensiunea loturilor, consumatori idempotenți, plafoane DLQ.
Gunoi/pauze: tuning GC, închirieri tampon, punerea în comun a obiectelor în limite rezonabile.
I/O/disc: I/O asincron, compresie, compresie a răspunsurilor cu un nivel rezonabil.

8) Limite și protecție

Temporizări bugetare: de sus în jos pentru a evita cascadele.
Limita ratei/găleți token: degradare previzibilă în loc de „moarte lungă”.
Întrerupător de circuit și umbrire cu prioritate scăzută.
Backpressure: semnale și constrângerea concurenței adânc în lanț.
Pereți etanși: piscine de izolare pentru punctele finale critice.
Idempotency: chei pentru repetiții sigure sub retrase.

9) Instrumente și când să le alegeți

k6 - JS laconic, suport excelent pentru rata de sosire, integrare și grafice.
Gatling - Scala DSL, generator de înaltă performanță.
JMeter - ecosistem flexibil, bogat; convenabil pentru protocoale/pluginuri.
Locust - script-uri Python, convenabil pentru logica complexă a fluxului de utilizator.
Vegeta/hey/wrk - microbenchies și punctul rulează pe HTTP.
tc/netem, toxiproxi - injecţie de degradare a reţelei.
Flamegraph/profiler - căutați puncte fierbinți CPU/heap.

10) Exemple (schițe)

k6 (model deschis, mix criterii finale)

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 (pași și 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"))

Planul de încărcare (schelet YAML)

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: 2m

11) Automatizare și ciclu de viață

Perf-fum în fiecare PR (termen scurt de criterii finale cheie).
Nightly „capacitate” rulează pe scenă cu rapoarte și artefacte de profil.
Porți în CI/CD: construiți fișier atunci când regresați p95/p99> X% din creșterea ratei de referință sau de eroare.
Versionarea liniilor de bază și depozitarea profilelor/flamegrafurilor ca artefacte.
Etichete de relevanță: ce serviciu/punct final este acoperit, ce profil de trafic este utilizat.

12) Anti-modele

Generatorul și serviciul de testare pe aceeași mașină → rezultate distorsionate.
Numai modelul închis (VU) pentru APIback-uri → subrezire și judecată greșită.
Rulează pe o bază de date goală/memorie cache fără un start rece.
Nu există distribuții realiste (toate interogările sunt aceleași).
Fără telemetrie (RPS/latență numai pe partea generatorului).
Comparație fără linii de bază stabile și controlul mediului.
„Optimizarea” printr-un timeout crescut în loc de corectarea cauzei.

13) Lista de verificare a arhitectului

1. SLO și sarcină tipică/vârf definit?
2. Este selectat modelul corect (deschis/închis) și profilul de trafic descris?
3. Standul este echivalent în configurație și topologie, există un mod rece/fierbinte?
4. Telemetrie și profile activate, rana de testare etichetat?
5. Rulează: linia de bază/rampă/spike/stres/înmuiere - acoperit?
6. Punctele de saturație sunt fixe și marja de siguranță planificată?
7. Limite configurate, întrerupătoare, backprescher, idempotență, politici de umbrire?
8. Există porți CI pentru regresia p95/p99 și rata de eroare, sunt liniile de bază versionate?
9. După remedieri - reprogon și playbook actualizare de putere?
10. Zoom auto și planul de urgență documentat?

Concluzie

Testarea sarcinii și a stresului nu sunt „curse” unice, ci practică continuă de inginerie. Un model de trafic realist, standuri corecte, telemetrie și automatizare în CI/CD transformă performanța din „magie secretă” în abilitate metrică: știi unde este plafonul, cât de sigur este stocul și ce schimbări îmbunătățesc cu adevărat experiența utilizatorului.