Testarea sarcinii și profilurile de stres
Scurt rezumat
Testarea sarcinii este un test de sistem de performanță și reziliență în scenarii realiste și extreme. Baza succesului: modelul de trafic corect (deschis vs închis), SLO fix, metric pur (latență/debit/erori/saturație), date reprezentative, automatizare și repetabilitate. Rezultatul nu este o „cifră SPR”, ci o soluție: unde sunt blocajele, cât costă performanța, unde este pragul de eșec și cum se mișcă.
SLO/SLI și valorile țintă
SLO (exemplu): p95 API ≤ 250 ms, p99 ≤ 600 ms; eroare ≤ 0. 3 %/30 zile.
SLI: latență (p50/p95/p99), debit (RPS/CPS/QPS), saturație (CPU/heap/GC/FD/conn), ошибки (5xx, timeout), очереди (adâncime/lag), DB (încuietori, interogări line), кэш (hit-ratio).
Eroare și declanșatoare de saturație (de exemplu, procesor> 75% sau adâncime de coadă> X → degradare).
Tipuri de teste
1. Baseline/Benchmark - single service/endpoint, condiții „ideale”.
2. Încărcare - realistă „zi lucrătoare” + rampă-up/rampă-jos.
3. Stresul - crește sarcina la degradare și fixare breakpoint.
4. Spike - salt ascuțit (x2-x10 în secunde/minute).
5. Înmuiere/rezistență - termen lung (8-72 h): scurgeri de memorie, derivă de latență.
6. Capacitate - încărcare pas pentru curba de performanță și planificarea capacității.
7. Degradare/Chaos-mix - sarcină + eșecuri parțiale (bază de date lentă, cădere cache, applink „prăbușit”).
Modele de trafic: Deschis vs Închis
Model deschis (mai realist pentru Internet): utilizatorii vin cu intensitate λ (flux Poisson-like). Dacă sistemul încetinește, cererile sunt acumulate, nu „înghețate”.
Model închis - un număr fix de utilizatori virtuali (VU) cu think-time. Când întârzierea crește, SPR cade artificial - cu atenție cu concluziile.
Recomandare: pentru API-urile front-end utilizați modelul deschis (k6 'arrival-rate'), pentru scripturi sincrone interne - combinați cu închise.
Profile de încărcare (șabloane)
„Zi normală”: fundal de bază + fluctuații zilnice.
„Eveniment de vârf”: 10-30 minute înainte de start (încălzire), vârf ascuțit la start, platou, coadă.
„Turneu/flux”: trepte de scară, vârfuri repetate în intervale.
„Degradarea infrastructurii”: jumătate din memoria cache este goală, o regiune este oprită, latența PSP crește.
„Failover”: fluxurile de trafic la protecție în 1-5 minute; verificarea auto-scară/HPA/Încercați din nou furtuni.
Datele și pregătirea mediului
Date de testare: cardinalitate realistă (furnizori, valute, țări), câmpuri murdare, distribuții de interogări (Pareto/Zipf).
Secrete/PII: Anonimizare; chei/PSP - sandbox.
Mediu: stand perf dedicat, izolare de integrare (mock/stab), versiuni fixe.
Observabilitate: valori (Prometheus), busteni (Loki/ELK), urme (OTel). Înregistrați build-id-ul în răspunsuri.
Retrase antistorme și Idempotence
Retrai numai pentru operațiuni idempotente; setați bugetul de încercare (de exemplu, ≤ 10% din trafic).
Backoff exponențial + jitter; „prăbușirea” identice GETs.
Pentru plăți - chei idempotente și stări explicite.
Protecție împotriva turmei tunătoare: încuietori cache, SWR, semafoare locale.
Instrumente și modele
k6 (scripting, open-model, raportare bună), Locust (scripturi Python), Gatling (Scala), JMeter (o gamă largă de protocoale).
Protocoale: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; push server nu testează „ca GET”.
Generarea traficului: scalarea orizontală a generatoarelor, controlul blocajului rețelei.
Eliminarea profilelor: pprof/async-profiler/ebpf sub sarcină, rute OTel.
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)
}Procedura
1. Ipoteza → care blocajele sunt probabile (CPU, DB, cache, rețea, TLS, GC).
2. Profil → scenarii/rute, acțiuni de trafic, modele (deschise/închise), date.
3. Warm-up → cache/conexiuni/TLS/interpreți.
4. Creșterea etapei de → la intensitatea țintă.
5. Platou → colecție de metrici și urme stabile.
6. Stresul/declinul → găsi un punct de rupere, observați scara automată.
7. Analizați → corelați valorile, flamegraph, raportați și schimbați planul.
8. Repruf → repeta prin conducta CI (Regiunea Perf).
Analiza rezultatelor
Încărcare → întârziere/curbă de eroare: în căutarea cotului (capacitate).
Latență defalcare: rețea (DNS/TLS/connect), proxy, aplicație, bază de date, apeluri externe.
Saturație: CPU> 75-85%, pauză GC> p95, I/O așteaptă, coadă de sarcini.
Elasticitate: timp de reacție autoscale (HPA/KEDA), pornire la rece, încălzire cache.
Cost: $/1000 RPS la SLO țintă, previziuni bugetare de vârf.
Practici de inginerie
Indicatori de degradare: „cozi” p99, creșterea cozii, scăderea raportului lovit, creșterea încercărilor de retractare.
Excludeți confounderele: limitele descriptorului de fișiere, sysctl, conn-pool, 'reutilizare', lanțuri TLS, OCSP.
DB: indici/planuri/interogare cache, piscină de conexiune, operațiuni de lot, backpressure pe producători.
Cache: politica de dimensiune/evacuare, chei fierbinți, replicare.
Rețea/margine: HTTP/2/3, resumption≥70%, Brotli, cheie cache CDN, memorie cache pe niveluri.
Observabilitate sub sarcină
Valori: sistem (CPU/mem/IO), runtime (GC/heap), rețea (RTT/loss/ECN), L7 (p95/99, 5xx/429), cozi, clustere de baze de date/cache.
Trasee: includ prelevarea de probe pe „cozi” (pe bază de coadă), build-id/semne canare.
Jurnale: agregarea erorilor cu limitarea volumului (pentru a nu „forDOSor” log-pipeline).
Experimente: feature-flag-uri și configurații ar trebui să fie înregistrate în raport.
Automatizare și CI/CD
Perf-locuri de muncă în CI (fum 3-5 min, noapte 30-60 min, înmuiere săptămânală).
Limite de toleranță: latență/erori/resurse → "break build' în regresie.
Artefacte: grafice, flamegrafe, profile, rapoarte JSON (k6/jtl).
Versioning de date și scripturi, PR-review de script-uri perf.
iGaming/fintech specific
Turnee/meciuri: spike + platou; Încălzirea TLS/DNS/CDN, creșterea limitelor de piscină, rute gri pentru roboți.
Plăți/PSP: limite de nisip, idempotență, termene stricte; verificarea modului degrade (memoria cache a directorului, cozile).
Jackpot-uri/evenimente: atomicitate și consecvență, nu ia, se încarcă pe RNG-uri/playboarduri.
Antifraudă/AML: încărcare pe reguli/scoring ML, backpressure, deduplicarea evenimentelor.
Reglementare: măsurători de logare și versiuni la vârfuri, rapoarte pentru audit.
Lansarea listei de verificare
- Fixed SLO/SLI și linii roșii (eroare/latență/saturație).
- Scenariile de încărcare și profilurile sunt aprobate (deschise/închise, spike/soak/stres).
- Date realiste, PII mascate, integrări sandbox/mock.
- Observabilitate gata: metrici/trasee/busteni, etichete de lansare.
- Configurațiile de sistem (ulimit/sysctl/pools) sunt documentate.
- Auto-scară/cache plan de încălzire și criterii de rollback.
- Alerte de prag și plan de gardă.
- Este pregătit șablonul de raportare (diagrame, concluzii, acțiuni).
Erori comune
Testul cu model închis produce un rezultat „verde”, iar produsul scade (nu puteți ignora modelul deschis).
Datele nereprezentative (o monedă/un furnizor) → concluzii false.
Pregătirea zero: cache-uri reci/TLS/conexiuni → latență excesivă la început.
Retrai fără limite → furtună și cascadă cade.
Aceleași profiluri pentru toate serviciile → sărind peste „punctele fierbinți” reale.
Absența rundelor de înmuiere → scurgeri de memorie și derivă nu sunt vizibile.
Rezultate opace: nu există urme/flamegrafe → imposibilitatea de a localiza blocajul.
Mini playbook-uri
Definirea unui breakpoint
1. Pași de 10-20% din sarcina la fiecare 5-10 minute. 2) Fixați momentul în care p95 se ridică brusc și erori> SLO. 3) Eliminați profilurile CPU/DB/cache. 4) Planul de optimizare și repetați.
Reining în furtuni din spate
1. Restricționați bugetul de încercare și activați backoff + jitter. 2) Introduceți cerere-colaps/SWR. 3) Permite „mod degrad” (funcționalitate limitată). 4) Verificați de două ori idempotența.
Eveniment de vârf (turneu) - pre-plan
1. Încălziți CDN/DNS/TLS/piscine. 2) Creșterea țintă HPA, pregătiți rezerva. 3) Limite de rată separate pentru roboți. 4) Tablouri de bord în modul vârf, punte de comunicare de gardă.
Soak-noapte
1. 8-12 ore de sarcină stabilă. 2) Monitor heap/FD/conn/GC-pauze. 3) Verificați delta p95 și raportul de succes. 4) Fixați scurgerile și deriva.
Rezultat
Testarea încărcăturii este un proces decizional de inginerie, nu o "cursă pentru SPR. "Modelați profiluri reale (în special modelul deschis), capturați SLO-uri, luați valori și urme, căutați genunchiul de performanță și numărați costul performanței. Automatizați cursele, păstrați retragerile anti-furtună și planificați evenimentele de vârf - în acest fel platforma va fi previzibilă și stabilă în momentele cele mai stresante.