Benchmarking und Leistungsvergleich

Kurze Zusammenfassung

1. Formulieren Sie Hypothesen und Metriken.

2. Steuern Sie Variablen (Eisen, Kern, Energie, Hintergrundrauschen).

3. Sammeln Sie genügend Daten (Replikate, Konfidenzintervalle).

4. Führen Sie Profiling durch - ohne es können Sie das „Warum“ nicht verstehen.

5. Machen Sie repro: Skripte, Fixierung von Versionen und Artefakten.

Benchmark-Ziele und Geschäftskennzahlen

Durchsatz (Durchsatz): RPS/QPS/CPS, Aufzeichnungen/Sek.
Latenz: p50/p95/p99/Schwanzdichte.
Effizienz: Cost-per-1k RPS, Watt pro Transaktion, $/Millisekunde Verbesserung.
Stabilität: Jitter, Variabilität zwischen Zyklen/Knoten.
Elastizität: Wie skalieren die Indikatoren bei N × Ressourcen (Amdahl/Gustafson-Benchmarks)?

Methodik: Versuchsplanung

Die Hypothese: „Envoy mit HTTP/3 würde p95 TTFB bei gleichem RPS um 10-15% reduzieren“.
Vergleichseinheit: Version der Bild-/Config/Instance-Hardware.
A/B-Schema: Parallellauf auf identischer Umgebung; entweder ABAB/Latin Square, um die Auswirkungen der Drift zu reduzieren.
Anzahl der Wiederholungen: ≥ 10 kurze + 3 lange Läufe pro Konfiguration für nachhaltige Bewertungen.
Statistik: Median, MAD, Bootstrap-Konfidenzintervalle; nichtparametrische Tests (Mann-Whitney) für Schwanzverteilungen.
DoE (minimal): Ändern Sie jeweils eine Variable (OVAT) oder einen fraktionellen Faktorplan für 2-3 Faktoren (z. B. TLS-Profil × HTTP-Version × Kernel).

Überwachung von Variablen und Geräuschen

CPU governor: `performance`; Deaktivieren Sie „power save“.
Turbo/Throttling: Überwachen Sie Frequenzen, Temperaturen und Drosseln (sonst führt das Aufwärmen zu falschen Gewinnen).
NUMA/Hyper-Threading: IRQ und Prozesse verankern ('taskset/numactl'), Speicherlokalität messen.
C-Zustände/IRQ-Balance: Einstellungen erfassen; für Netzwerktests - pin IRQ für bestimmte Kerne.
Hintergrundprozesse: Sauberer Knoten, cron/backup/antivirus/updatedb ausschalten.
Netzwerk: stabile Pfade, feste MTU/ECN/AQM, kein Kanal Flatter.
Daten: gleiche Sätze, Kardinalität und Verteilungen.
Cache: Trennen Sie die „kalten“ (erster Durchgang) und „warmen“ (wiederholten) Modi, markieren Sie deutlich.

Benchmark-Klassen

1) Mikro-Benchmarks (Funktion/Algorithmus)

Ziel: Messung eines bestimmten Codes/Algorithmus.
Tools: Integrierte Benchmark-Frameworks (Go 'testing. B`, JMH, pytest-benchmark).
Regeln: JIT-Erwärmung, Millisekunden → Nanosekunden; Isolierung von GC; fester Samen.

2) Meso-Benchmarks (Komponente/Service)

HTTP-Server, Cache, Broker, Datenbank auf einem Knoten.
Werkzeuge: wrk/wrk2, k6 (offenes Modell), vegeta, ghz (gRPC), fio, sysbench, iperf3.
Regeln: Grenzen für Verbindungen/Dateien, Pools; CPU/IRQ/GC-Bericht.

3) Makro-Benchmarks (e2e/Anfragepfad)

Vollständiger Pfad: CDN/Edge → Proxy → Service → DB/Cache → Antwort.
Werkzeuge: k6/Locust/Gatling + RUM/OTel Tracing; realistische Mischung von Routen.
Regeln: näher an der Realität („schmutzige“ Daten, externe Systemverzögerungen), vorsichtig mit Retrays.

Satz von Metriken nach Schicht

Testvorlagen und Befehle

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

Statistiken und Gültigkeit

Wiederholungen: mindestens 10 Durchläufe, Outliers ausschließen (robust: Median/MAD).
Konfidenzintervalle: 95% CI-Bootstrap für p95/p99 und Medium.
Effektgröße: relative Veränderung und ihr CI (z.B. − 12% [− 9%; − 15%]).
Praktische Relevanz: 10% p95-Reduktion zum Preis von + 30% CPU - lohnt sich das?
Diagramme: Violin/ECDF für Verteilungen, „Sättigungskurven“ (RPS→latency).

Profiling und Engpasslokalisierung

CPU: `perf`, `async-profiler`, eBPF/pyroscope; flamegraph vorher und nachher.
Alloc/GC: Laufzeitprofile (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-Tasten, TTL, eviction Ursache.

Berichte und Artefakte

• git SHA Bild, Flags kompilieren/optimieren.
• Kernel/Netzwerk-Configs (sysctl), Treiberversionen/NIC/Firmware.
• Topologie (vCPU/NUMA/HT), Governor, Temperatur/Frequenzen.
• Daten: Größe, Kardinalität, Verteilungen.
• Was zu veröffentlichen: Tabellen p50/p95/p99, Fehler/sec, throughput, Ressourcen (CPU/RAM/IO), CI.
• Artefakte: Run-Skripte, Grafiken, Flamegraph, rohe JSON/CSV-Ergebnisse, Umgebungsprotokoll.

Faire Vergleiche (fair benchmarking)

Identische Limiter (conn pool, keepalive, TLS Ketten, OCSP Stapeln).
Vereinbarte Timeouts/Retrays und HTTP-Version (h2/h3).
Temperaturbilanz: Aufwärmen auf Gleichgewicht (kein Turbo-Boost-Effekt).
Faire Caches: entweder beide „kalt“ oder beide „warm“.
Netzsymmetrie: gleiche Routen/MTU/ECN/AQM.
Zeitbudget: DNS/TLS/connect - explizit zählen oder gleich ausschließen.

Anti-Muster

Ein Lauf → „Fazit“.
Mischen von Modi (Teil kalt, Teil warm) in einer Serie.
Ein geschlossenes Modell anstelle eines offenen für die Internet-Last → eine falsche „Nachhaltigkeit“.
Nicht gemeldete Retrays → „RPS steigt“ auf Kosten von Takes und Cascading 5xx.
Vergleich auf verschiedenen Drüsen/Kernen/Energieschaltungen.
Keine Profilierung → Blind-Optimierung.
Spielen Sie mit GC/Heap ohne Profilanalyse → Schwanzregression.

Praktische Rezepte

1. Umgebung fixieren (Skript 'env _ capture. sh`).

2. Aufwärmen (5-10 min), Frequenzen/Temperaturen fixieren.

3. Führen Sie N Wiederholungen von kurzen + 1 langen Lauf.

4. Entfernen Sie Profile (CPU/alloc/IO) an der Spitze.

5. CI/Grafiken zählen, Artefakte sammeln.

6. Lösung: Annahme/Ablehnung der Hypothese, Bildung der nächsten Schritte.

• RPS-Stufen (10% Schritt) → Wir fixieren p95/Fehler → finden das „Knie“.
• Wir erstellen ein Diagramm von RPS→latency und RPS→CPU: Wir sehen die Grenze und die Kosten für weitere%.

Spezifität für iGaming/Fintech

Kosten pro Millisekunde: Ordnen Sie die Verbesserungen nach dem $ -Effekt (Konversion/Abfluss/PSP-Limits).
Peaks (Matches/Turniere): Benchmarks spike + plateau mit TLS/CDN/Caches warm.
Zahlungen/PSP: Messen Sie Ende-zu-Ende mit Sandbox-Limits, Idempotenz und Reaktionen auf Degradation; Fixieren Sie Time-to-Wallet mit Proxy-Metriken.
Anti-Fraud/Bot-Filter: Fügen Sie ein Regelprofil in den Makro-Benz ein (false-positive-rate, latency addition).
Führer/Jackpots: Testen Sie Hot Keys/Ranking, Sperren, Atomarität.

Benchmarking-Checkliste

• Hypothese/Metriken/Erfolgskriterium.
• Variablenüberwachung (Stromversorgung/NUMA/IRQ/Netzwerk/Cache).
• Ablaufplan (Replikate, Dauer, Aufwärmen).
• Trennung „kalt/warm“ Modi.
• Profilerstellung aktiviert (CPU/alloc/IO/DB).
• Statistik: CI, Signifikanztests, Grafiken.
• Artefakte und Repro-Skripte im Repository (IaC für Stand).
• Bericht mit „Verbesserungskosten“ und Empfehlungen.
• Retest nach Optimierungen (Regression perf).

Mini-Bericht (Vorlage)

Ziel: p95 API um 15% reduzieren ohne CPU-Wachstum> 10%.
Methode: A/B, k6 open-model 1k rps, 10 × 3 Durchläufe, warm cache.
Gesamt: p95 − 12% [− 9%; − 15%], CPU + 6%, 5xx unverändert.
Flamegraph: ↓ JSON Serialisierung (− 30% der CPU) hat sich der Engpass in die DB verlagert.
Die Lösung: die Optimierung zu übernehmen; Der nächste Schritt besteht darin, die DB-Anforderungen einzubinden.
Artefakte: Diagramme, Profile, Configs, rohe JSON.

Summe

Gutes Benchmarking ist eine strenge Methodik + ehrliche Vergleiche + statistische Gültigkeit + Profiling + Reproduzierbarkeit. Stellen Sie Hypothesen auf, kontrollieren Sie die Umgebung, zählen Sie Konfidenzintervalle, veröffentlichen Sie Artefakte und treffen Sie Entscheidungen über die Kosten der Verbesserung. So erhalten Sie keine schöne Figur in der Präsentation, sondern einen echten Gewinn an Geschwindigkeit und Vorhersagbarkeit der Plattform.