Test di carico e stress

Test di carico e stress

1) Perché è necessario

• Conferma la capacità (quante sessioni RPS/competitive il sistema può reggere con un SLO specificato).
• Trova le gole di bottiglia (CPU/IO/BD/reti/blocchi/pool).
• Configura budget e gate in CI/CD.
• Ridurre il rischio di rilascio (regressione p95/p99, aumento degli errori a picco).
• Pianifica capacità/costo (scale-out e riserve).

2) Tipi di perf test

Load (carico di lavoro) - Traffico realistico vicino ai picchi; convalidazione SLO.
Stress - aumento a/oltre il limite del comportamento in caso di degrado in cui si rompe.
Spike (Impulso) - Aumento rapido del carico di lavoro, elasticità/scale automatico.
Soak/Endurance (prolungato): ore/ore di fuoriuscita, frammentazione, deriva latency.
Capacity/Scalability: come cambia throughput/latency quando scale-out; la legge Amdal/Gustafson.
Smoke perf è un breve test «fumogeno» su ogni lancio (performance-saniti).

3) Modelli di generazione di traffico

Modello chiuso (fixed VUS/concertency): «N» degli utenti, tutti fanno la coda al client. Rischio di nascondere il sovraccarico.
Modello aperto (arrival rate) - Flusso di richieste con intensità di (req/s), come nella vita reale. Più corretto per API pubbliche.

La legge Little è «L = © x W».
Per il pool/servizio: parallelismo minimo ≈ x W (aggiungi 20-50% della riserva).
Dove «back» è throughput, «W» è il tempo medio di manutenzione.

4) Profili di carico e script

User journey mix: quote di script (login, browse, deposit, checkout...).
Think-time - interruzioni utente (distribuzione: esponenziale/lognormale).
Data profile: dimensioni delle risposte, payload, variabilità dei parametri.
Correlazione: collegare i passi (cookie/token/ID) come in un flow reale.
Freddo/caldo/hot kash, singole prove.
Read vs Write - Bilanciamento letture/record, Idampotenza per i retrai.
Regione Multi: RTT, distribuzione POP/ASN.

5) Ambiente di test

Isolamento: lo stand è vicino alla vendita per topologia/regolazione (ma non «picchiamo» il prone).
Dati: maschera PII, volumi, indici come in vendita.
Generatori di carico: non sono collegati a CPU/rete; runner distribuiti, sincronizzazione temporale.
Osservabilità: metriche/trailer/logi, sintetico sul perimetro, esportazione di profili CPU/heap.

6) Metriche e SLI

Throughput: transazioni RPS/in secondi.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: 5xx/4xx/errori di dominio.
Saturation: CPU, load avg, GC, IOPs/Latitudine su disco, network, pool wait.
Business SLI: successo del deposito ≤ 5s, conferma ordine ≤ 2s.

Le soglie vengono prese da SLO (ad esempio, "99. 95% ≤ 300 ms"), monitorare il burn-rate durante il test.

7) Ricerca di colli di bottiglia (tecnica)

1. Mantenere il sistema stabile al 60-80% del carico di lavoro di destinazione.
2. Ingrandisci i gradini (ramp) → fissa dove crescono p95/p99 e error-rate.

• code nei pool (DB/HTTP),
• crescita WAIT/lock (database),
• Pausa GC/heap,
• retransmits/packet loss di rete,
• Latitudine a disco/guasti alla cache.
• 4. Localizza la ricerca binaria nel percorso di query, profilatori (CPU/alloc/lock-profile).
• 5. Fissa «bottiglia» con un sintonizzatore di prova.

8) Comportamento sotto stress

Graceful degradation: limiti, circuiti-breakers, code con backpressure, modalità «accettata in elaborazione».
Retrai: massimo 1, solo idipotenti; jitter; Il budget dei retraes è del 10% della RPS.
Fail-open/Fail-closed - Per le dipendenze non critiche, tolleri fail-open (cash/stub).
Cascading failure - Isolamento dei pool/quota (bulkhead), timeout rapido, disattivazione delle funzioni (feature flags).

9) Strumenti (selezione per attività)

k6 (aperto/aperto-model, veloce, comodo in CI).
JMeter (ricco di ecosistema, GUI/CLI, plugin, ma più pesante).
Gatling (Scala DSL, prestazioni elevate).
Locust (Python, flessibilità degli script).
Vegeta/hey/wrk (micro-benchi e controllo rapido).

Regola: uno strumento «principale» + CLI leggero per lo smoke-perf in PR.

10) Esempi (snippet)

10. 1 k6 (modello aperto con arrival rate)

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 (idea profilo)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Asserzioni tempo/codice.

10. 3 Locust (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) Dati, correlazione, preparazione

I dati seed sono directory, utenti, bilanci, token, come in vendita.
Occultamento/anonimizzazione di PII; generare sintetici sopra le distribuzioni reali.
Correlazione: estrarre l'ID/token dalle risposte (RegExp/JSONPath) e utilizzarlo nelle fasi successive.

12) Osservazione durante i test

RED-dashboard (Rate, Errors, Duration) lungo le rotte.
Excplars - Passa dalle metriche alle piste (trace _ id).
Loghi di errore: sampling + aggregazione, duplicati/idampotenza.
Sistema: CPU/GC/heap, unità/rete, pool wait.
Database: richieste top, blocchi, indice scan, bloat.

13) Automazione e performance-gate

CI: test brevi su merge (ad esempio k6 2-3 minuti) con soglie.
Nightly/Week: soak/stress lunghi in un ambiente separato; rapporti e trend.
Release canarie: analisi SLO (errore-rate, p95) come «gate» promozione.
Regressione: baseline vs Bild corrente; alert in peggioramento> X%.

14) Pianificazione della capacità e costo

Curve throughput→latency: definisci knee point (ginocchio) - dopo di esso p99 cresce bruscamente.
Scale-out: misura l'efficienza della scalabilità (delta RPS/Delta nodi).
Costo: «RPS $/ora», riserva per eventi di punta + DR-riserva.

15) Anti-pattern

Picchiare un proto senza controllo o testarlo in un ambiente «vuoto» che non assomiglia a un prato.
Modello chiuso con U fisso che nasconde il sovraccarico.
La mancanza di think-time/dati è un successo irrealistico di cache o viceversa di tempesta verso i sorgenti.
Uno script «/ping »invece del flow personalizzato.
«Vediamo solo RPS e ritardo medio».
I retrai incontrollati sono →-DDoS.
Miscelare test e ottimizzazioni senza fissare ipotesi/modifiche.

16) Foglio di assegno (0-30 giorni)

0-7 giorni

Definire SLI/SLO e profili di traffico di destinazione (mix, think-time, dati).
Selezionate l'utensile (k6/JMeter/Locust) e sollevate i dashboard RED.
Preparare lo stand e i dati seed, disattivare i limiti di terze parti/captchi.

8-20 giorni

Creare script open-model (arrival rate), freddo/caldo/caldo.
Avvia load stress spike; Fissare knee point e colli di bottiglia.
Incorporare performance-gate in CI (micro-progone).

21-30 giorni

Test soak 4-24 ore: perdite/deriva GC, stabilizzazione.
Documentare i limiti, il piano di capacità, l'illustrazione «RPS→p95/oshibki».
Preparare il runbook «come aumentare i limiti/scale» e «come degradare».

17) Metriche di maturità

Ci sono profili realistici (mix, think-time, dati) che coprono l' 80% del traffico.
RED-dashboard + traccia sono collegati per tutti i test.
Le performance-gate bloccano i rilasci quando regrediscono p95/errori.
Capacità e knee point sono documentati su servizi chiave.
Test mensili soak/stress e report di dinamica.
La resistenza a «spike» è confermata dallo skale automatico e dall'assenza di cascade-fail.

18) Conclusione

I test di carico sono una pratica di ingegneria regolare, non una misura singola. Modellate gli utenti reali (open-model), misurate ciò che riflette l'esperienza del cliente (SLI/SLO), mantenete l'osservabilità e i «gate» in CI/CD, eseguite stress/spike/soak-test e fissate knee point. Gli eventi di punta e i cigni neri diventano scenari gestiti, mentre le prestazioni diventano un parametro prevedibile e misurabile per la piattaforma.