Testarea încărcăturii și stresul

Testarea încărcăturii și stresul

1) De ce aveți nevoie de ea

• Confirmați capacitatea (câte sesiuni RPS/competitive va rezista sistemul dat SLO).
• Găsiți blocaje (CPU/IO/DB/rețele/încuietori/piscine).
• Configurați bugete de performanță și porți în CI/CD.
• Reduceți riscul de eliberare (regresie p95/p99, creștere de eroare maximă).
• Capacitatea/costul planului (scară și rezerve).

2) Tipuri de teste perf

Încărcare: trafic realist aproape de vârfuri; Validarea SLO.
Stresul: creșterea la/peste limita → comportamentul de degradare în cazul în care se rupe.
Spike: salt rapid de sarcină → elasticitate/autoscale.
Înmuiere/Rezistență: ore/zi → scurgeri, fragmentare, derivă latență.
Capacitate/scalabilitate: cum se schimbă debitul/latenţa cu scalarea; Legea Amdal/Gustafson.
Fum perf: un scurt „fum” pe fiecare versiune (demnitate de performanță).

3) Modele de generare a traficului

VU fixe/concurență: utilizatorii „N”, fiecare făcând cereri pentru a → coada de așteptare pe client. Riscul de a ascunde supraîncărcarea.
Rata de sosire: un flux de aplicații cu intensitate λ (req/s), ca în viața reală. Mai corect pentru API-urile publice.

Little's Law: 'L = λ × W'.
Pentru piscină/serviciu, paralelismul minim ≈ „λ × W” (se adaugă 20-50% din inventar).
În cazul în care „λ” este de transfer, „W” este timpul mediu de serviciu.

4) Profiluri și scenarii de încărcare

Journey mix utilizator: acțiuni de scripturi (conectare, răsfoire, depozit, checkout...).
Think-time: pauze de utilizare (distribuții: exponențiale/lognormale).
Profilul de date: dimensiunea răspunsurilor, sarcina utilă, variabilitatea parametrilor.
Corelație: pași de legătură (cookie-uri/jetoane/ID) ca într-un flux real.
Cache rece/cald/fierbinte: rulează individuale.
Read vs Write: echilibrul citirilor/înregistrărilor, idempotența pentru retroys.
Multi-regiune: RTT, distribuţie POP/ASN.

5) Mediu de testare

Izolare: standul este aproape de produs în topologie/setări (dar nu „bate” produsul).
Date: mascare PII, volume, indici ca în vânzări.
Generatoare de sarcină: nu se odihnesc împotriva procesorului/rețelei; alergători distribuiţi, sincronizarea timpului.
Observabilitate: metrici/trasee/busteni, sintetice pe perimetru, export de profile CPU/heap.

6) Metrics și SLI

Debit: SPR/Tranzacţii/sec

Latență: p50/p95/p99, TTFB, timp server vs rețea.
Erori: cota de erori 5xx/4xx/domeniu.
Saturație: CPU, avg de încărcare, GC, IOps/latență disc, rețea, piscină așteptați.
Business SLI: ≤ 5s succes depozit, ≤ 2s confirmarea comenzii.

Luați pragurile de la SLO (de exemplu, "99. 95% ≤ 300 ms), monitor arde rata în timpul rulării.

7) Găsirea blocajelor (tehnică)

1. Încălziți în mod constant sistemul cu 60-80% din sarcina țintă.
2. Creșteți pașii (rampa) → fixați unde p95/p99 și rata de eroare cresc.

• cozi în bazine (DB/HTTP)
• creșterea WAIT/locks (DB),
• GC-pauses/heap,
• retransmiteri de rețea/pierderi de pachete,
• discul latență/memorie cache ratează.
• 4. Localizați: căutare binară după calea de interogare, profileri (CPU/allock/lock-profile).
• 5. Fixați „sticla” → tuning → repetând rularea.

8) Comportament sub stres

Degradare grațioasă: limite, întrerupătoare de circuit, cozi de presopunctură, acceptate pentru procesare.
Retroactive: maxim 1, numai idempotente; jitter; bugetul retribuției ≤ de 10% din SPR.
Fail-open/Fail-closed: pentru dependențe non-critice, permite fail-open (cache/stubs).
Eșec în cascadă: izolarea bazinelor/cotelor (perete etanș), timeout-uri rapide, dezactivarea „netedă” a funcțiilor (steaguri caracteristice).

9) Instrumente (selecție pentru sarcină)

k6 (JavaScript, open/open-model, rapid, convenabil în CI).
JMeter (bogat în ecosistem, GUI/CLI, plugin-uri, dar mai grele).
Gatling (Scala DSL, de înaltă performanță).
Locust (Python, flexibilitate scripting).
Vegeta/hey/wrk (micro-banci si verificare rapida).

Regulă: un instrument „principal” + CLI lumina pentru stilou de fum în PR.

10) Exemple (fragmente)

10. 1 k6 (model deschis cu tarif de sosire)

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 (ideea profilului)

Thread Group + Pasping Thread или Fir de concurență (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Afirmații după timp/cod.

10. 3 Lăcuste (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) Date, corelație, pregătire

Date despre semințe: directoare, utilizatori, solduri, jetoane - ca în vânzări.
Mascare/anonimizare PII; generarea de sintetice pe partea de sus a distribuțiilor reale.
Corelație: Extrageți ID-uri/jetoane din răspunsuri (RegExp/JSONPath) și utilizați în pașii următori.

12) Observabilitate în timpul rulează

Tablouri de bord ROȘII (rată, erori, durată) de-a lungul rutelor.
Exemplare - trecerea de la valori la urme (trace_id).
Jurnale de erori: eșantionare + agregare, duplicate/idempotence.
Sistem: CPU/GC/heap, discuri/rețea, piscină așteptați.
DB: interogări de top, încuietori, scanări index, bloat.

13) Porti de automatizare si performanta

CI: scurte runde de îmbinare (de ex. k6 2-3 minute) cu praguri.
Noapte/săptămână: înmuiere/stres lung într-un mediu separat; rapoarte și tendințe.
Canare lansează: analiza SLO (error-rate, p95) ca „poarta” promoției.
Regresii: valoarea iniţială vs construirea curentului; alertă la deteriorare> X%.

14) Planificarea capacității și costul

Curbe throughput→latency: definiți punctul genunchiului - după ce p99 crește brusc.
Scalare: Măsurați eficiența scalării (delta/delta nodului RPS).
Cost: „RPS pe $/oră”, rezervă pentru evenimente de vârf + DR-reserve.

15) Anti-modele

Bate în prod fără control sau de testare într-un mediu „gol”, nu ca prod.
Model închis cu VU fixe care ascund supraîncărcarea.
Lipsa de think-time/date → cache-uri nerealiste, sau invers - furtuna la sursa.
Un „/ping „script în loc de flux personalizat.
Lipsa de observabilitate: „vedem doar SPR și întârzierea medie”.
Retroactive necontrolate → auto-DDoS.
Amestecarea testului și optimizări fără fixarea ipotezelor/modificărilor.

16) Lista de verificare (0-30 zile)

0-7 zile

Definiți profilurile de trafic SLI/SLO și țintă (mix, think-time, date).
Selectați instrumentul (k6/JMeter/Locust), ridicați tablourile de bord roșii.
Pregătiți datele din stand și semințe, dezactivați limitele/captchas terțe părți.

8-20 zile

Construiți scenarii: open-model (rata de sosire), cache rece/cald/fierbinte.
Rulați sarcina → stres → spike; fixați punctul genunchiului și blocajele.
Implementarea porților de performanță în CI (micro-run).

21-30 zile

Test de înmuiere 4-24h: scurgeri/derivă GC, stabilizare.
Limitele documentelor, planul de capacitate, ilustrațiile „RPS→p95/oshibki”.
Pregătiți runbook „cum să creșteți limitele/scara” și „cum să se degradeze”.

17) Valorile maturității

Există profiluri realiste (mix, think-time, date) care acoperă ≥ 80% din trafic.
Tablourile de bord roșii + trasarea sunt conectate pentru toate testele.
Performance gates bloc eliberează atunci când regresează p95/erori.
Capacitatea și punctul genunchiului sunt documentate de servicii cheie.
Lunar înmuiere/stres ruleaza si rapoarte de progres.
Rezistența la „spike” este confirmată de autoscale și absența cascadei.

18) Concluzie

Testarea sarcinii este o practică inginerească regulată, nu o măsurare unică. "Modelați utilizatori reali (open-model), măsurați ceea ce reflectă experiența clientului (SLI/SLO), păstrați observabilitatea și porțile în CI/CD, efectuați alergări de stres/spike/înmuiere și fixați punctul genunchiului. Apoi evenimentele de vârf și lebedele negre se transformă în scenarii ușor de gestionat, iar performanța se transformă într-un parametru previzibil și măsurabil al platformei.