Test di carico e stress
1) Termini e obiettivi
Load test - Controllo nell'intervallo di lavoro (target RPS/competitività) contro SLO (ad esempio p95 <200 ms, error rate <0. 5%).
Stress test - fuori (prima/oltre la saturazione CPU/BD/rete), osservazione del degrado e meccanica di recupero.
Spike test - picchi di carico bruschi (x N in minuti).
Soak/Endurance è un test a lungo termine (ore/ore) per la ricerca di fuoriuscite, deriva GC, frammentazione, crescita delle code.
Capacity test - Calcola la platea di larghezza di banda (saturation point) e le scorte.
Obiettivi: confermare la SLO, fissare la platea, capire i colli di bottiglia, calibrare il ridimensionamento automatico e i limiti.
2) Modello di traffico aperto vs chiuso
Modello chiuso (concurrency-driven) - Numero fisso di utenti virtuali (VUS), ciascuno dopo la risposta effettua un think time.
Modello aperto (arrival-rate) - Intensità di richiesta fissa (RPS), indipendentemente dalle risposte.
Little’s Law: `L = λ W`
«L» è il numero medio di richieste di manutenzione simultanee,
'' - Intensità (RPS),
«W» è il tempo medio di risposta.
Da qui la valutazione della concorrenza del generatore: «concurrency ≈ target _ RPS p95 _ latency».
3) Metriche: cosa misuriamo
Ritardo SLI: p50/p90/p95/p99 e coda p99. 9; separati per le vie calde e fredde.
Errori: «5xx», «4xx» (validi/nevalidi), timeouts, aborted.
Larghezza di banda: RPS resistente, throughput thread/byte.
Risorse: CPU, RAM/heap, interruzioni GC, IOPS/lat, bandwidth di rete, numero di connessioni/FD.
Code e backpreser: profondità, tempo di attesa, numero di query shed/limited.
Efficienza cache: hit/miss, tempeste di riscaldamento.
Database/cache/code: p95 richieste, blocchi, conflitti, pool utilization.
4) Stand e dati
Equivalenza di configurazione: versione software, limiti (uLimit, conntrack), configurazione JVM/GC, pool's.
Topologia: LBs, CDN, WAF, TLS, stessi hop di rete.
Dati: distribuzioni realistiche (dimensioni degli oggetti, chiavi calde/fredde, regionalità).
Partenza fredda/calda/calda: singole prove; è necessario testare la cache fredda.
Isolamento di sfondo - Disattiva i giubbotti/cronomi non ricorrenti o ne tiene conto.
5) Script (profili di carico)
1. Baseline: accelerazione a passo a RPS di destinazione, 10-30 minuti
2. Ramp & Hold: crescita fluida fino a X% sopra l'obiettivo, ritenzione e analisi delle code.
3. Spike: istantanea x 2- x 5 slancio di 1-5 min, quindi ritorno.
4. Stress to Failure - gradini prima dei guasti; fissiamo il primo punto di inattività SLO e il punto di astinenza.
5. Soak: 6-24 ore con una variabilità di traffico (giorno/notte), monitorando la velocità/deriva.
6. Mixed è una miscela di endpoint di distribuzione reale (Zipf/pareto), di peso diverso.
6) Processo passo passo
Identificare SLO e profili di traffico di destinazione.
Selezionare un modello di carico (aperto/chiuso), impostare arrival-rate o VUS.
Preparare i dati e le modalità calde/fredde.
Configura la telemetria (trailer/metriche/logi), la curvatura con la prova-ferita.
Riscaldamento e prova, raccolta di manufatti (profili CPU/heap, flame graphs, explorer/slow-logs database).
Analisi dei colli di bottiglia, creazione di action items.
Riprogetto dopo i record, aggiornamento del basline e capacity playbook.
7) Stretti e fissaggi tipici
Servizio CPU-bound: profilazione, eliminazione di funzioni calde, allocazioni, ramificazioni; vettorizzazione, cache-friendly della struttura.
Rete/TLS: keep-alive, HTTP/2/3, connection pooling, timeout corretti, riduzione della capacità.
Database: indici, batch, query preparate, pool di connettori, suddivisione R/W, cache dei risultati, deduplicazione delle richieste.
Cache: dimensioni, TTL, richiest coalescing, protezione da tempeste, warming, palline regionali.
Code/broker: limiti di piacevolezza/parallelismo, dimensioni batch, idempotent consumers, soffitti DLQ.
Garbatage/pause: tuning GC, affitto di buffer, object pooling entro limiti ragionevoli.
I/O/disco: input/output asincrono, compressione, compressione delle risposte con un livello ragionevole.
8) Limiti e protezione
Budget timeout - dall'alto verso il basso per evitare cascate.
Rate limit/token-baquet - degrado prevedibile anziché «morte prolungata».
Circuito breaker e shading di bassa priorità durante la saturazione.
Backpressure: segnali e limitazione del parallelismo all'interno della catena.
Bullkheads - Isolamento dei pool sotto endpoint critici.
Idempotency - chiavi per ripetizioni sicure sotto i retrai.
9) Strumenti e quando selezionarli
k6 - JS conciso, ottimo supporto arrival-rate, integrazione e grafica.
Gatling - Scala DSL, generatore ad alte prestazioni.
JMeter è flessibile, ricco di ecosistemi; conveniente per protocolli/plugin.
Locust - Script Python, utile per la logica complessa del flow personalizzato.
Vegeta/hey/wrk - microbenchi e test puntali su HTTP.
tc/netem, toxiproxy - iniezione di degrado di rete.
Flamegraph/profiler - Cerca «luoghi caldi» CPU/heap.
10) Esempi (sketch)
k6 (modello aperto, mix di endpoint)
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 (gradini e 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"))Piano carico (scheletro 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: 2m11) Automazione e ciclo di vita
Perf-smoke in ogni PR (prova breve degli endpoint chiave).
Test notturni «capacity» su uno sterzo con report e manufatti di profili.
Gate in CI/CD: fail bild a regressione p95/p99> X% da basline o crescita error rate.
Versioning dei basline e conservazione dei profili/flaimgram come artefatti.
Tag di rilevanza: quale servizio/endpoint è coperto, quale profilo di traffico utilizzato.
12) Anti-pattern
Il generatore e il servizio di test sulla stessa macchina hanno ottenuto risultati distorti.
Solo un modello chiuso (VUS) per API-bak può essere sottovalutato e valutato male.
Test su un database/cache vuoto senza una partenza fredda.
Nessuna distribuzione realistica (tutte le richieste sono uguali).
Nessuna telemetria (solo RPS/latency dal generatore).
Confronto senza basline stabili e controllo dell'ambiente.
«Ottimizzazione» con un timeout aumentato anziché correggere la causa.
13) Assegno-foglia dell'architetto
1. Definito SLO e carico standard/picco?
2. Il modello selezionato (open/closed) è corretto e il profilo del traffico è stato pianificato?
3. Lo stand è equivalente a configure e topologia, c'è una modalità fredda/calda?
4. La telemetria e i profili sono inclusi, le etichette di prova-rana vengono impostate?
5. Baseline/ramp/spike/stress/soak - coperto?
6. Fissare i punti di saturazione e pianificare la riserva (safety margin)?
7. Limiti, breaker, backprescher, idempotency, polizze di shading?
8. Ci sono CI-gate su regress p95/p99 e error rate, basline versionati?
9. Dopo i registri, riprogettare e aggiornare il playbook in base alla potenza?
10. Il piano di scalabilità automatica e le modalità di emergenza sono documentati?
Conclusione
I test di carico e stress non sono una singola gara, ma una pratica di ingegneria continua. Un modello di traffico realistico, gli stand corretti, la telemetria e l'automazione di CHI/CD trasformano le prestazioni da «magia segreta» in una capacità guidata da metriche: sai dove si trova il soffitto, quanto la riserva è sicura e quali cambiamenti migliorano l'esperienza degli utenti.