Compararea comparațiilor și a performanțelor

Scurt rezumat

1. Formulați ipoteze și valori.

2. Variabile de control (hardware, core, putere, zgomot de fundal).

3. Colectați suficiente date (replici, intervale de încredere).

4. Faceți profilare - fără ea nu puteți înțelege „de ce”.

5. Do repro: scripturi, versiuni de fixare și artefacte.

Obiective de referință și valori de afaceri

Debit: RPS/QPS/CPS, scrie/sec

Latență: p50/p95/p99/densitatea cozii.
Eficiență: Cost-per-1k RPS, watt per tranzacție, îmbunătățire $/milisecundă.
Stabilitate: jitter, variabilitate inter-ciclu/nod.
Elasticitate: modul în care indicatorii sunt scalați la N × resursă (indicatori de referință Amdahl/Gustafson).

Metodologie: proiectare experimentală

Ipoteză: „Trimisul cu HTTP/3 va reduce p95 TTFB cu 10-15% cu același SPR”.
Unitatea de comparație: build/config/instanță versiune de fier.
A/B diagramă: paralel rula pe mediu identic; sau ABAB/Piața Latină pentru a reduce impactul derivei.
Numărul de repetiții: ≥ 10 scurte + 3 rulaje lungi pe configurație pentru evaluări stabile.
Statistici: mediană, MAD, bootstrap intervale de încredere; teste non-parametrice (Mann-Whitney) pentru distribuții „cu coadă”.
DoE (minim): Modificați o variabilă la un moment dat (OVAT) sau factoring factorial pentru 2-3 factori (de exemplu, profilul TLS × versiunea HTTP × kernel).

Controlul variabilelor și al zgomotului

Guvernatorul CPU: „performanță”; dezactivează „economisirea puterii”.
Turbo/Throttling: frecvențe de monitorizare, temperaturi și accelerare (în caz contrar încălzirea va da câștiguri false).
NUMA/Hyper-Threading: pin IRQs și procese ("taskset/numactl'), măsura localitatea de memorie.
Soldul C-states/IRQ: remediați setările; pentru testele de rețea - PIN IRQ pentru nuclee specifice.
Procese de fundal: curățați nodul, dezactivați cron/backup/antivirus/updatedb.
Rețea: căi stabile, fixe MTU/ECN/AQM, nici un flutter canal.
Date: aceleași seturi, cardinalitate și distribuții.
Cache: separați modurile "rece" (prima trecere) și "cald' (repetare), marcați explicit.

Clase de referință

1) Micro repere (funcție/algoritm)

Scop: Măsurați un anumit cod/algoritm.
Instrumente: cadre de bancă încorporate (Go 'testing. B ', JMH, pytest-benchmark).
Reguli: încălzire JIT, milisecunde → nanosecunde; Izolarea GC; semințe fixe.

2) Repere Meso (componentă/serviciu)

Server HTTP, cache, broker, bază de date pe un singur nod.
Instrumente: wrk/wrk2, k6 (model deschis), vegeta, ghz (gRPC), fio, sysbench, iperf3.
Reguli: limite de conexiune/fișier, piscine; Raport CPU/IRQ/GC.

3) Repere macro (e2e/calea de solicitare)

Mod complet: CDN/edge proxy service răspuns DB/cache.
Instrumente: k6/Locust/Gatling + RUM/OTel trasare; un amestec realist de rute.
Reguli: mai aproape de realitate (date „murdare”, lag-uri de sisteme externe), frumos cu retras.

Măsurători după strat

Șabloane și comenzi de testare

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

Statistici și valabilitate

Se replică: minim 10 rulează, se exclud outliers (robust: median/MAD).
Intervale de încredere: bootstrap 95% CI pentru p95/p99 și mijloace.
Dimensiunea efectului: modificare relativă şi IÎ (de exemplu − 12% [− 9%; − 15%]).
Semnificație practică: o scădere de 10% a p95 la un preț de + 30% CPU - merită?
Grafice: vioară/ECDF pentru distribuții, „curbe de saturație” (RPS→latency).

Bottleneck profilare și localizare

Procesor: „perf”, „async-profiler”, eBPF/piroscop; flamegraph înainte și după.
Allocation/GC: profile de rulare (Go pprof/Java JFR).
I/O: "iostat", "blktrace", "fio --lat_percentiles=1'.
Сеть: 'ss -s', 'ethtool -S', 'dropwatch', 'tc -s qdisc'.
БД: 'EXPLICA (ANALIZA, BUFFERS)', pg_stat_statements, slowlog.
Bani gheaţă: cheile de sus, TTL, cauza evacuării.

Raportare și artefacte

• git SHA construi, compilare/optimizare steaguri.
• Kernel/configurații de rețea (sysctl), versiuni de driver/NIC/firmware.
• Topologie (vCPU/NUMA/HT), guvernator, temperatură/frecvențe.
• Date: dimensiune, cardinalitate, distribuții.
• Ce se publică: tabele p50/p95/p99, eroare/sec, debit, resurse (CPU/RAM/IO), CI.
• Artefacte: executați scripturi, grafice, flamegraph, rezultate JSON/CSV brute, protocol de mediu.

Analiza comparativă corectă

Limitatoare identice (conn pool, keepalive, lanț TLS, OCSP capsare).
Termene negociate/retribuții și versiunea HTTP (h2/h3).
Echilibrul temperaturii: încălzirea până la echilibru (fără efect turbo-boost).
Cache-uri corecte: Fie „rece”, fie ambele „calde”.
Simetria rețelei: aceleași rute/MTU/ECN/AQM.
Bugetul de timp: DNS/TLS/connect - conta în mod explicit sau exclude în mod egal.

Anti-modele

O rulare → „ieșire”.
Amestecarea modurilor (parte rece, parte caldă) într-o singură serie.
Un model închis în loc de unul deschis pentru încărcarea pe Internet → falsă „stabilitate”.
Reîncontabil → „SPR crește” la costul de ia și cascadă 5xx.
Comparație pe diferite glande/nuclee/circuite de putere.
Fără profilare → optimizare oarbă.
Redarea cu GC/heap fără analiza profilului → regresia cozii.

Retete practice

1. Remediați mediul (script' env _ capture. sh ').

2. Încălziți-vă (5-10 min), înregistrați frecvențe/temperaturi.

3. Efectuați repetări N pe termen scurt + 1 lung.

4. Eliminați profilurile (CPU/allow/IO) la vârf.

5. Calculați CI/grafice, colectați artefacte.

6. Soluție: acceptați/respingeți ipoteza, formați pașii următori.

• Pașii SPR (10% din pas) → repara p95/erori → a găsi „genunchiul”.
• Construim un program de RPS→latency și RPS→CPU: vedem granița și costul de încă%.

iGaming/fintech specific

Costul pe milisecundă: îmbunătățiri de rang cu $ efect (conversie/Churn/PSP limite).
Vârfuri (meciuri/turnee): spike + repere de platou cu încălzirea TLS/CDN/cache.
Plăți/PSP: măsoară end-to-end cu limite de nisip, idempotență și reacții la degradare; fixați Time-to-Wallet cu măsurători proxy.
Filtrele antifraudă/bot: includ un profil de regulă în banca macro (rata fals pozitivă, aditiv de latență).
Lideri/jackpot-uri: Testați tastele fierbinți/clasament, încuietori, atomicitate.

Benchmarking lista de verificare

• Ipoteză/metrică/criteriu de succes.
• Monitorizare variabilă (power/NUMA/IRQ/network/cache).
• Run plan (replici, durata, warm-up)
• Separare rece/caldă.
• Profilare activată (CPU/allow/IO/DB).
• Statistici: CI, teste de semnificație, grafice.
• Artefacte și scripturi repro în depozit (IaC pentru bancă).
• Raportați cu „costuri de îmbunătățire” și recomandări.
• regresie perf.

Mini-raport (șablon)

Scopul este de a reduce API-ul p95 cu 15% fără creșterea procesorului> 10%.
Metodă: A/B, k6 open-model 1k rps, 10 × 3 ruleaza, cache cald.
Total: p95 − 12% [− 9%; − 15%], CPU + 6%, 5xx nemodificat.
Flamegraph: ↓ serializarea JSON (− 30% CPU), blocajul a trecut la baza de date.
Decizie: acceptare optimizare; următorul pas este să cereri de baze de date lot.
Artefacte: grafică, profile, configurații, JSON brut.

Total

Analiza comparativă bună este o metodologie riguroasă + comparații echitabile + validitate statistică + profilare + reproductibilitate. Ipoteza, controlul mediului, citirea intervalelor de încredere, publicarea artefactelor și luarea deciziilor privind costul îmbunătățirii. Deci, nu veți obține o figură frumoasă în prezentare, ci o creștere reală a vitezei și predictibilității platformei.