Benchmarking e confronto delle prestazioni

Breve riepilogo

1. Tracciate ipotesi e metriche.

2. Controllare le variabili (ferro, nucleo, alimentazione, rumore di sfondo).

3. Raccogliere abbastanza dati (repliche, intervalli di fiducia).

4. Fai una profilassi senza che tu capisca perché.

5. Ripro: script, fissa versioni e manufatti.

Obiettivi benchmark e metriche aziendali

Throughput: RPS/QPS/CPS, record/s.
Ritardo (latency): p50/p95/p99/densità di coda.
Efficienza: Cost-per-1k RPS, watt per transazione, $/millisecondo di miglioramento.
Stabilità: jitter, variabilità tra cicli/nodi.
Elasticità: come si scalano i valori in N x risorsa (Amdahl/Gustafson).

Metodologia: progettazione esperimento

Ipotesi: «Avvoy con HTTP/3 riduce p95 TTFB del 10-15% con lo stesso RPS».
Unità di confronto: versione del bilide/config/istanza di ferro.
Schema A/B: prova parallela su un ambiente identico; o ABAB/Latin Square per ridurre l'impatto della deriva.
Numero di ripetizioni: 10 brevi + 3 lunghi test di configurazione per valutazioni sostenibili.
Statistiche: mediana, MAD, spaziatura di fiducia; Test non parametrici (Mann-Whitney) per le distribuzioni di coda.
DoE (minimo) - Modificare una variabile alla volta (OVAT) o un piano fattore di frazione per 2-3 fattori (ad esempio, profilo TLS x HTTP x kernel).

Controllo delle variabili e dei rumori

CPU governor: `performance`; disattivare «power save».
Turbo/Throttling - Monitoraggio di frequenze, temperature e trottling (altrimenti il riscaldamento darà false vincite).
NUMA/Hyper-Threading: fissa l'IRQ e i processi ('taskset/numactl') e misura la memoria locale.
C-states/IRQ bilancia: fissa le impostazioni; per i test di rete - pin IRQ per nuclei specifici.
Processi di sfondo: filo pulito, disattivare cron/backup/antivirus/updatedb.
Rete: percorsi stabili, MTU/ECN/AQM fissi, nessun flutter canale.
I dati sono gli stessi set, i cardinalit e le distribuzioni.
Cache: separa «freddo» (primo passaggio) e «caldo» (ripetuto), contrassegna esplicitamente.

Classi di benchmark

1) Micro benchmark (funzione/algoritmo)

L'obiettivo è misurare un codice/algoritmo specifico.
Strumenti - Framework incorporati (Go 'testing. B`, JMH, pytest-benchmark).
Regole: riscaldamento JIT, millisecondi di nanosecondi; Isolamento GC; seed fisso.

2) Meso-benchmark (componente/servizio)

Server HTTP, cache, broker, database su un solo nodo.
Strumenti: wrk/wrk2, k6 (open model), vegeta, ghz (gRPC), fio, sysbench, iperf3.
Regole: limiti di connessione/file, pool; rapporto CPU/IRQ/GC.

3) Macro-benchmark (e2e/percorso query)

Percorso completo: CDN/edge proxy, servizio di database/cache, risposta.
Strumenti: k6/Locust/Gatling + RUM/OTel tracking; un mix realistico di percorsi.
Regole: più vicino alla realtà (dati «sporchi», lame di sistemi esterni), con attenzione ai retrai.

Insieme di metriche per livello

Modelli di test e comandi

bash iperf3 -s # server iperf3 -c <host> -P 8 -t 60 # parallel, stable bandwidth

bash wrk2 -t8 -c512 -d5m -R 20000 https://api. example. com/endpoint \
--latency --timeout 2s

javascript export const options = {
scenarios: { open: { executor: 'constant-arrival-rate', rate: 1000, timeUnit: '1s',
duration: '10m', preAllocatedVUs: 2000 } },
thresholds: { http_req_failed: ['rate<0. 3%'], http_req_duration: ['p(95)<250'] }
};

bash fio --name=randread --rw=randread --bs=4k --iodepth=64 --numjobs=4 \
--size=4G --runtime=120 --group_reporting --filename=/data/testfile

bash sysbench oltp_read_write --table-size=1000000 --threads=64 \
--pgsql-host=... --pgsql-user=... --pgsql-password=... prepare sysbench oltp_read_write --time=600 --threads=64 run

bash perf stat -e cycles,instructions,cache-misses,L1-dcache-load-misses \
-- <your_binary> --bench

Statistiche e validi

Ripetizioni: almeno 10 test, escludere outlieri (robasto: mediana/MAD).
Intervalli di fiducia: il 95% CI per p95/p99 e media.
Effetto-dimensione: modifica relativa e il suo CI (ad esempio - 12% [- 9%; - 15%]).
Valore pratico: riduzione del p95 del 10% con un costo di CPU del 30%?
Grafici: violin/ECDF per le distribuzioni, curve di saturazione (RPS→latency).

Profilazione e localizzazione dello spazio ristretto

CPU: `perf`, `async-profiler`, eBPF/pyroscope; flamegraph prima e dopo.
Alloc/GC: profili runtime (Go pprof/Java JFR).
I/O: `iostat`, `blktrace`, `fio --lat_percentiles=1`.
Сеть: `ss -s`, `ethtool -S`, `dropwatch`, `tc -s qdisc`.
БД: `EXPLAIN (ANALYZE, BUFFERS)`, pg_stat_statements, slowlog.
Cache: top chiavi, TTL, eviction causa.

Reporting e manufatti

• git SHA bild, bandiere compilazione/ottimizzazione.
• Configi kernel/network (sysctl), versioni driver/NIC/firmware.
• Topologia (vCPU/NUMA/HT), governor, temperatura/frequenza.
• I dati sono la dimensione, il cardinalitetto, la distribuzione.
• Cosa pubblicare: tabelle p50/p95/p99, errore/secondi, throughput, risorse (CPU/RAM/IO), CI.
• Artefatti: script di prova, grafica, flamegraph, JSON crude/CSV risultati, protocollo di ambiente.

Paragoni onesti (fair benchmarking)

Vincoli identici (conn pool, keepalive, TLS catene, OCSP stapling).
Timeout/retrai e HTTP coerenti (h2/h3).
Equilibrio termico: riscaldamento all'equilibrio (senza effetto turbo-bust).
Le catene giuste sono o fredde o calde.
Simmetria di rete: stesso percorso/MTU/ECN/AQM.
Tempo budget: DNS/TLS/connect - Contarli chiaramente o escluderli allo stesso modo.

Anti-pattern

Un test dice «conclusione».
Miscelazione di modalità (parte fredda, parte calda) in una serie.
Un modello chiuso, invece di un carico di lavoro aperto a Internet, è una falsa «resilienza».
Retrai non registrati «RPS cresce» a costo di riprese e 5xx a cascata.
Confronto su diversi sistemi di ferro/core/energia.
Senza profilassi, ottimizzazione alla cieca.
Gioco con GC/heap senza analisi dei profili di regressione delle code.

Ricette pratiche

1. Blocca l'ambiente (script 'env _ capture'. sh`).

2. Riscaldare (5-10 min), fissare frequenze/temperature.

3. Eseguire N ripetizioni brevi + 1 prova lunga.

4. Rimuovi profili (CPU/alloc/IO) all'apice.

5. Contate i grafici CI, raccogliete i manufatti.

6. Decisione: accettare/rifiutare l'ipotesi, formare next steps.

• I gradini RPS (10% del passo) registrano i p95/errori e troviamo il ginocchio.
• Facciamo un programma di RPS→latency e RPS→CPU, vediamo il confine e il valore del prossimo%.

Specifico per iGaming/Fintech

Costo millisecondo: classificare i miglioramenti a $ $ (conversione/uscita/limiti PSP).
Picchi (partite/tornei): benchmark spike + plateau con riscaldamento TLS/CDN/cache.
Pagamenti/PSP: Misurare end-to-end con limiti sandbox, idipotenza e reazioni al degrado; fissare Time-to-Wallet con le metriche proxy.
Antifrod/bot-filtri - Includi nel profilo macro-bench delle regole (false-positive-rate, latency integrator).
Leader/jackpot: prova chiavi hot/classificazione, blocchi, atomatologia.

Foglio di assegno di benchmarking

• Ipotesi/metriche/criterio di successo.
• Controllo delle variabili (alimentazione/NUMERA/IRQ/rete/cache).
• Piano di prova (repliche, durata, riscaldamento).
• Separazione modalità freddo/calore.
• Profilassi abilitata (CPU/alloc/IO/database).
• Statistiche: CI, test di rilevanza, grafici.
• Gli artefatti e i repro nel repository (IaC per lo stand).
• Report con «costi di miglioramento» e suggerimenti.
• Retest dopo le ottimizzazioni.

Mini report (modello)

Obiettivo: ridurre il p95 API del 15% senza crescita CPU> 10%.
Metodo: A/B, k6 open-model 1k rps, 10 x 3 test, warm cache.
Totale: p95 - 12% [- 9%; - 15%], CPU + 6%, 5xx invariato.
Flamegraph - Serializzazione JSON (-30% CPU), il punto di bottiglia si è spostato nel database.
La soluzione è accettare l'ottimizzazione; il prossimo passo è il controllo delle richieste di database.
Grafici, profili, confighi, JSON crude.

Totale

Un buon benchmarking è una metodologia rigorosa + paragoni onesti + valenza statistica + profilassi + riproducibilità. Fare ipotesi, controllare l'ambiente, leggere gli intervalli di fiducia, pubblicare gli artefatti e prendere decisioni sui costi di miglioramento. In questo modo non si ottiene una bella cifra nella presentazione, ma un reale aumento di velocità e prevedibilità della piattaforma.