Test di carico e profili di stress

Breve riepilogo

I test di carico consentono di verificare le prestazioni e la stabilità dei sistemi in scenari realistici ed estremi. Base del successo: modello di traffico corretto (open vs closed), SLO, metrica pura (latency/throughput/errori/saturazione), dati rappresentativi, automazione e ripetibilità. Il risultato non è «RPS», ma la soluzione: dove sono le strette, quanto costano le prestazioni, dove è la soglia di rifiuto e come spostarle.

SLO/SLI e metriche di destinazione

SLO (esempio): p95 API da 250 ms, p99 da 600 ms; Errore ≤ 0. 3 %/30 giorni.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Trigger di errore e sensori (ad esempio CPU> 75% o queue depth> X degrado).

Tipi di test

1. Baseline/Benchmark è un singolo servizio/endpoint, condizioni «perfette».
2. Load è un giorno di lavoro realistico + ramp-up/ramp-down.
3. Stress - Aumentiamo il carico fino a degrado e fissazione breakpoint.
4. Spike è un salto brusco (x2-x10 in secondi/minuti).
5. Soak/Endurance - Prova a lungo termine (8-72 ore): perdita di memoria, deriva di latitanza.
6. Capacity è un carico a fasi per la creazione di una curva delle prestazioni e la pianificazione della capacità.
7. Degradation/Chaos-mix - Carico di lavoro + guasti parziali (database rallentato, cache in calo, aplinco a presa).

Modelli di traffico: Open vs Closed

Open model (più realistico per Internet) - Gli utenti vengono visualizzati con un'intensità di flusso simile a Poisson. Se il sistema frena, le richieste vengono accumulate e non congelate.
Closed model: numero fisso di utenti virtuali con think-time. Quando aumenta la latenza, RPS diminuisce artificialmente - attenta alle conclusioni.
Raccomandazione: per le API frontali, usate l'open model (k6 'arrival-rate'), per gli script sincroni interni - combinare con closed.

Profili di carico (modelli)

«Giorno normale» - Sfondo base + fluttuazioni diurne.
«Pick-event»: 10-30 minuti prima della partenza (riscaldamento), spike brusca in partenza, platea, coda.
«Torneo/Stream», un albero di gradini, picchi ripetuti a intervalli.
Degrado dell'infrastruttura: metà cache vuota, una regione disattivata, maggiore latitudine PSP.
Failover: il traffico si sposta su una riserva in 1-5 minuti; Controlliamo le tempeste auto-scale/HPA/Retry.

Dati e preparazione dell'ambiente

Dati di prova: cardinalizio realistico (provider, valute, paesi), campi «sporchi», distribuzione delle richieste (Pareto/Zipf).
Segreti/PII - Anonimato; chiavi/PSP - sandbox.
Ambiente: perf-stand selezionato, isolamento dalle integrazioni (mock/branco), versioni fisse.
Osservabilità: metriche (Prometheus), fogli (Loki/ELK), piste (OTel). Fissare build-id nelle risposte.

Antiparticolato e idempotia

Retrai solo per operazioni idipotenti; puntate retry-budget (ad esempio, 10% del traffico).
Exponential backoff + jitter; «collapsing» identici a GET.
Per i pagamenti - chiavi idipotenti e stati espliciti.
Protezione da thundering herd: cache, SWR, semafori locali.

Strumenti e pattern

k6 (script, open-model, buoni rapporti), Locust (script Python), Gatling (Scala), JMeter (una vasta gamma di protocolli).
Protocolli HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; non testare come GET.
Generazione di traffico: scalabilità orizzontale dei generatori, controllo dello stretto di rete.
Mangia i profili: pprof/async-profiler/ebpf sotto carico, piste OTEL.

Mini esempio k6 (open-model + spike):

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)
}

Metodologia di esecuzione

1. Ipotesi su quali colli di bottiglia sono probabili (CPU, database, cache, rete, TLS, GC).
2. Profilo di script/percorsi, quote di traffico, modelli (open/closed), dati.
3. Riscaldamento della cache/connettori/TLS/interpreti.
4. Aumenta il livello più alto fino a raggiungere l'intensità di destinazione.
5. La piattaforma raccoglie metriche e piste stabili.
6. Stress/declino, ricerca del punto di scatto, osservazione dello skale automatico.
7. Analisi, correlazione tra metriche, flamegraph, report e piano di modifica.
8. Ripetizione ripetizione tramite pipline CI (Regolution Perf).

Analisi dei risultati

Curva di carico, ritardo/errore: cerca il ginocchio (capacity).
Rete (DNS/TLS/connect), proxy, applicazione, database, chiamate esterne.
Saturazione: CPU> 75-85%, GC pausa> p95, I/O, coda di attività.
Elasticità: tempo di reazione della schermata automatica (HPA/KEDA), avvio freddo, riscaldamento della cache.
Costo: $/1000 RPS con obiettivo SLO, previsione di bilancio di punta.

Tecniche di ingegneria

Indicatori di degrado: «coda» p99, aumento delle code, calo dell'hit-ratio, aumento dei tentativi di retrai.
Escludi i confounder: limiti dei descrittori di file, sysctl, conn-pool, 'reuseport', TLS, OCSP.
Database: indici/piani/cache di query, pool di connessioni, operazioni di batch, backpressure per i produttori.
Cache: dimensioni/eviction-criterio, chiavi hot, repliche.
Rete/edge: HTTP/2/3, resumption≥70%, Brotli, chiave cache CDN, tered-cache.

Osservabilità sotto carico

Metriche: di sistema (CPU/mem/IO), runtime (GC/heap), di rete (RTT/loss/ECN), L7 (p95/99, 5xx/429), code, cluster database/cache.
Tracciati: abilita la sequenza su «coda» (tail-based), contrassegni build-id/canarini.
Logi: aggregazione degli errori con limitazione del volume (per non dire «ZDOSo» loga-pipline).
Gli esperimenti di feature-flags e confighi devono essere rilevati nel report.

Automazione e CI/CD

Perf-jobs in CI (smoke 3-5 min, nightly 30-60 min, week soak).
I limiti di tolleranza sono latitanza/errore/risorse → «Rompiamo il Bild» durante la regressione.
Artefatti: grafici, flamegraphs, profili, report JSON (k6/jtl).
Versioning dei dati e degli script, script perf-review.

Specifico per iGaming/Fintech

Tornei/partite: spike + plateau; riscaldamento TLS/DNS/CDN, limiti di pool elevati, percorsi «grigi» per i bot.
Pagamenti/PSP: limiti sandbox, idipotenza, timeout rigoroso; Controllo degrade-mode (cache, code).
Jackpot/Ivent: atomatologia e sequenza, nessuna ripresa, carico di RNG/liderbord.
Antifrode/AML: carico di lavoro su regole/ML-screen, backpressure, deduplicazione degli eventi.
Regolazione: logica le metriche e le versioni ai picchi, report per il controllo.

Assegno foglio di avvio

SLO/SLI e linee rosse (errore/latenza/saturazione).
Script e profili di carico approvati (open/closed, spike/soak/stress).
Dati realistici, PII mascherati, integrazioni - sandbox/mock.
L'osservabilità è pronta: metriche, trailer, tag di rilascio.
I sistemi configli (ulimit/sysctl/pools) sono documentati.
Piano di display automatico/riscaldamento cache e criteri rollback.
Alert di soglia e piano di comunicazione dei comandi (on-call).
Il modello di riferimento (grafici, conclusioni, attività) è stato preparato.

Errori tipici

Il test closed-model visualizza il risultato «verde» e il campionamento viene declinato (non potete ignorare il modello aperto).
Dati non ripresentabili (moneta/provider) rivelano false conclusioni.
Preparazione zero: cache fredda/TLS/connettori e latitanza eccessiva alla partenza.
Retrai senza limiti. Tempesta e cadute a cascata.
Gli stessi profili per tutti i servizi → il pass dei punti caldi reali.
La mancanza di soak-test e la perdita di memoria e la deriva non sono visibili.
Risultati opachi: nessuna traccia/fleimgramma non può essere localizzata.

Mini playbook

Definizione larghezza di banda limite (breakpoint)

1. Step 10-20% di carico ogni 5-10 min 2) Registra il momento in cui p95 è in forte crescita e errori> SLO. 3) Togliere i profili CPU/database/cache. 4) Piano di ottimizzazione e ripetizione.

Contenimento delle tempeste retraiche

1. Limita retry-budget e abilita backoff + jitter. 2) Inserisci richiest-collapsing/SWR. 3) Consenti modalità degrada (funzione limitata). 4) Ricontrolla Idampotenza.

Pick event (torneo) - pre-piano

1. Scalda CDN/DNS/TLS/pool. 2) Aumentare il target HPA, preparare la riserva. 3) Limiti rate separati per i bot. 4) Dashboard «modalità di punta», ponte di collegamento on-call.

Soak-notte

1. 8-12 ore di carico stabile. 2) Monitor heap/FD/conn/GC-sessions. 3) Incrociamo delta p95 e hit-ratio. 4) Registriamo le perdite e la deriva.

Totale

I test di carico sono un processo di progettazione, non una corsa RPS. Modellare profili reali (in particolare open model), fissare SLO, rimuovere metriche e piste, cercare il ginocchio delle prestazioni e contare i costi delle prestazioni. Automatizzare i test, tenere i retrai anti-tempesta e pianificare gli eventi di punta - così la piattaforma sarà prevedibile e resistente nei momenti più stressanti.