Analiza porównawcza i porównanie wyników

Krótkie podsumowanie

1. Sformułować hipotezę i metryki.

2. Zmienne sterujące (sprzęt, rdzeń, moc, szum tła).

3. Zbierz wystarczającą ilość danych (repliki, przedziały ufności).

4. Zrób profilowanie - bez niego nie możesz zrozumieć „dlaczego”.

5. Do repro: skrypty, naprawianie wersji i artefaktów.

Cele odniesienia i wskaźniki biznesowe

Przepustowość: RPS/QPS/CPS, pisze/sec

Opóźnienie: p50/p95/p99/gęstość ogona.
Wydajność: Cost-per-1k RPS, wata na transakcję, poprawa $/milisekund.
Stabilność: jitter, zmienność między cyklami/węzłami.
Elastyczność: w jaki sposób wskaźniki są skalowane przy N × zasobów (wartości odniesienia Amdahla/Gustafsona).

Metodologia: projekt eksperymentalny

Hipoteza: „Wysłannik z HTTP/3 zmniejszy p95 TTFB o 10-15% przy tym samym RPS”.
Jednostka porównawcza: build/config/instance wersja żelaza.
Schemat A/B: równoległy przebieg w identycznym środowisku; lub ABAB/Latin Square w celu zmniejszenia wpływu dryfu.
Liczba powtórzeń: ≥ 10 krótkich + 3 długich biegów na konfigurację dla stabilnych ocen.
Statystyki: mediana, MAD, bootstrap przedziały ufności; badania parametryczne (Mann-Whitney) dla rozkładu „ogonowego”.
DoE (minimum): Zmień jedną zmienną na raz (OVAT) lub silnikową dla 2-3 czynników (na przykład profil TLS × wersja HTTP × jądro).

Regulacja zmiennych i hałasu

Gubernator procesora: „wydajność”; wyłączyć „oszczędzanie mocy”.
Turbo/Throttling: monitorowanie częstotliwości, temperatur i rozgrzewania (w przeciwnym razie ocieplenie da fałszywe wygrane).
NUMA/Hyper-Threading: pin IRQ i procesy ("taskset/numactl'), pomiar lokalizacji pamięci.
Saldo C-states/IRQ: naprawić ustawienia; dla testów sieciowych - pin IRQ dla określonych rdzeni.
Procesy tła: czysty węzeł, wyłączyć cron/backup/antivirus/updatedb.
Sieć: stabilne ścieżki, stałe MTU/ECN/AQM, brak trzepotania kanału.
Dane: te same zestawy, kardynalność i dystrybucje.
Pamięć podręczna: oddzielne tryby „zimne” (pierwsze przejście) i „ciepłe” (powtarzające się), wyraźnie oznaczone.

Klasy wzorcowe

1) Mikro wartości odniesienia (funkcja/algorytm)

Cel: Zmierzyć określony kod/algorytm.
Narzędzia: wbudowane ramy ławki (Go 'testing. B ', JMH, punkt odniesienia).
Zasady: JIT rozgrzewka, milisekund → nanosekund; izolacja GC; stałe nasiona.

2) Wskaźniki Meso (komponent/usługa)

Serwer HTTP, pamięć podręczna, broker, baza danych na jednym węźle.
Narzędzia: wrk/wrk2, k6 (model otwarty), vegeta, ghz (gRPC), fio, sysbench, iperf3.
Zasady: limity połączeń/plików, puli; Sprawozdanie CPU/IRQ/GC.

3) Makro wartości odniesienia (e2e/ścieżka żądania)

Pełny sposób: CDN/edge → proxy → service → DB/cache → odpowiedź.
Narzędzia: k6/Locust/Gatling + RUM/OTel odwzorowanie; realistyczna mieszanka tras.
Zasady: bliżej rzeczywistości („brudne” dane, opóźnienia systemów zewnętrznych), starannie z retras.

Metryka według warstwy

Szablony testów i polecenia

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

Statystyka i ważność

Replikaty: minimum 10 ciągów, z wyłączeniem odstających (wytrzymałych: mediana/MAD).
Przedziały ufności: bootstrap 95% CI dla p95/p99 i środków.
Wielkość efektu: zmiana względna i wartość CI (np. − 12% [− 9%; − 15%]).
Praktyczne znaczenie: 10% spadek p95 w cenie + 30% CPU - czy warto?
Wykresy: skrzypce/ECDF dla dystrybucji, „krzywe nasycenia” (RPS → latency).

Profilowanie i lokalizacja wąskich gardeł

Procesor: „perf”, „async-profiler”, eBPF/piroskop; flamegraf przed i po.
Alloc/GC: profile runtime (Go pprof/Java JFR).
I/O: 'jostat', 'blktrace', 'fio --lat_percentiles=1'.
Сета: 'ss -s',' ethtool -S', 'dropwatch', 'tc -s qdisc'.
СИ: 'EXPLAIN (ANALYZE, BUFFERS)', pg_stat_statements, slowlog.
Gotówka: górne klucze, TTL, przyczyna eksmisji.

Sprawozdawczość i artefakty

• git SHA budować, kompilacja/optymalizacja flagi.
• Konfiguracje jądra/sieci (sysctl), wersje sterowników/NIC/firmware.
• Topologia (vCPU/NUMA/HT), gubernator, temperatura/częstotliwości.
• Dane: rozmiar, kardynalność, dystrybucje.
• Co opublikować: tabele p50/p95/p99, błąd/sec, przepustowość, zasoby (CPU/RAM/IO), CI.
• Artefakty: uruchom skrypty, wykresy, flamegraf, surowe wyniki JSON/CSV, protokół środowiskowy.

Fair benchmarking

Identyczne ograniczenia (basen conn, utrzymywany, łańcuch TLS, zszywanie OCSP).
Negocjowane timeouts/retrays i wersja HTTP (h2/h3).
Równowaga temperatury: ocieplenie do równowagi (bez efektu turbo-boost).
Fair caches: Zarówno „zimne”, jak i „ciepłe”.
Symetria sieci: te same trasy/MTU/ECN/AQM.
Budżet czasu: DNS/TLS/connect - policzyć lub wykluczyć w równym stopniu.

Anty-wzory

Jeden uruchom → „wyjście”.
Mieszanie trybów (część zimna, część ciepła) w jednej serii.
Zamknięty model zamiast otwartego dla ładunku internetowego → fałszywe „stabilność”.
Niezapisane retrasy → „RPS rośnie” kosztem zabrania i kaskadowania 5xx.
Porównanie różnych gruczołów/rdzeni/obwodów mocy.
Brak profilowania → optymalizacja ślepej.
Gra z GC/hałda bez analizy profilu → regresja ogona.

Przepisy praktyczne

1. Naprawić środowisko (skrypt '_ capture. sh ").

2. Ogrzewanie (5-10 min), rekordowe częstotliwości/temperatury.

3. Prowadzenie N powtórzeń krótkiej + 1 długiej perspektywie.

4. Usuń profile (CPU/alloc/IO) na szczycie.

5. Obliczanie CI/wykresów, zbieranie artefaktów.

6. Rozwiązanie: zaakceptować/odrzucić hipotezę, utworzyć kolejne kroki.

• Kroki RPS (10% kroku) → naprawić p95/błędy → znajdź „kolano”.
• Budujemy harmonogram RPS → latency i RPS → CPU: widzimy granicę i koszt dalszych%.

iGaming/specyficzne dla fintechu

Koszt na milisekundę: Poprawa rankingu przez $ efekt (konwersja/churn/PSP limity).
Szczyty (mecze/turnieje): spike + plateau benchmarks z TLS/CDN/cache ocieplenie.
Płatności/PSP: pomiar końcowy z limitami piaskownicy, idempotencja i reakcje na degradację; naprawić czas do portfela za pomocą mierników proxy.
Filtry przeciw oszustwom/bot: zawierają profil reguły w makro ławce (fałszywie dodatni wskaźnik, dodatek opóźnienia).
Liderzy/jackpoty: Testuj gorące klucze/ranking, zamki, atomowość.

Lista kontrolna benchmarkingu

• Hipoteza/metryka/kryterium sukcesu.
• Monitorowanie zmiennych (power/NUMA/IRQ/network/cache).
• Plan operacyjny (repliki, czas trwania, rozgrzewka)
• Separacja na zimno/ciepło.
• Włączone profilowanie (CPU/alloc/IO/DB).
• Statystyki: CI, testy znaczenia, wykresy.
• Artefakty i skrypty repro w repozytorium (IaC dla ławki).
• Sprawozdanie zawierające „koszty poprawy” i zalecenia.
• regresja perf.

Mini-report (szablon)

Celem jest zmniejszenie API p95 o 15% bez wzrostu procesora> 10%.
Metoda: A/B, k6 otwarty model 1k rps, 10 × 3 działa, ciepły pamięć podręczna.
Ogółem: p95-12% [− 9%; − 15%], procesor + 6%, 5xx bez zmian.
Flamegraph: α serializacja JSON (− 30% procesor), wąskie gardło przeniosło się do bazy danych.
Decyzja: zaakceptować optymalizację; następnym krokiem jest załadowanie żądań bazy danych.
Artefakty: grafika, profile, konfiguracje, surowy JSON.

Razem

Dobre porównanie to rygorystyczna metodologia + rzetelne porównania + ważność statystyczna + profilowanie + odtwarzalność. Hipotezować, kontrolować środowisko, czytać przedziały ufności, publikować artefakty i podejmować decyzje dotyczące kosztów poprawy. Więc nie dostaniesz piękną postać w prezentacji, ale prawdziwy wzrost prędkości i przewidywalności platformy.