基準和性能比較

簡短摘要

基準測試是一個實驗，而不是「運行wrk 5分鐘」。主要原則：

1.建立假設和指標。

2.控制變量（鐵、核心、電源、背景噪音）。

3.收集足夠的數據（副本、置信區間）。

4.進行分析-沒有它就無法理解「為什麼」。

5.制作repro：腳本，修復版本和人工制品。

基準目標和業務指標

吞吐量（throughput）： RPS/QPS/CPS,記錄/秒。
延遲（latency）：p50/p95/p99/尾巴密度。
效率：Cost-per-1k RPS，每筆交易瓦，$/毫秒的改進。
穩定性：jitter，循環/nods之間的變化。
彈性：在N ×資源下，指標如何縮放（Amdahl/Gustafson基準）。

方法論： 實驗設計

假設： 「具有HTTP/3的Envoy將p95 TTFB降低了10-15％，具有相同的RPS。」

比較單位：法案/config/實例鐵版本。
A/B電路：在相同環境中並行運行；或ABAB/拉丁廣場以減少漂移的影響。
重復次數：≥ 10個短+3個長運行配置,用於持續評估。
統計信息：中位數，MAD，butstrapom置信區間；「尾巴」分布的非參數測試（Mann-Whitney）。
DoE（最小值）：每次更改一個變量（OVAT）或2-3因子的分數因子計劃（例如TLS配置文件× HTTP版本×內核）。

控制變量和噪聲

CPU governor: `performance`;禁用「power save」。
Turbo/Throttling：監測頻率、溫度和trottling（否則加熱會產生錯誤的收益）。
NUMA/超線程：固定IRQ和進程（「taskset/numactl」）,測量內存的位置。
C-states/IRQ平衡：捕獲設置；對於網絡測試-每個特定內核的pin IRQ。
背景過程：純凈的紙幣,關閉cron/backup/antivirus/updatedb。
網絡：穩定路徑，固定MTU/ECN/AQM，沒有通道傳動器。
數據：相同的集合，基數和分布。
緩存：分開「冷」（第一次通過）和「溫暖」（重復）模式,明確標記。

基準類

1）微型基準（函數/算法）

目的：測量特定代碼/算法。

工具： 嵌入式基準框架（Go'testing.B`, JMH, pytest-benchmark).

規則：JIT加熱，毫秒→納秒；GC隔離；固定種子。

2） Meso基準（組件/服務）

HTTP服務器，緩存，經紀人，單個代碼上的DB。
工具：wrk/wrk2，k6（開放模型），vegeta，ghz（gRPC），fio，sysbench，iperf3。
規則：連接/文件限制，池；CPU/IRQ/GC報告。

3）宏觀基準（e2e/查詢路徑）

完整路徑：CDN/ed → ge proxy →服務→ DB/緩存 →響應。
工具：k6/Locust/Gatling+RUM/OTel預覽；路線的現實混合。
規則：更接近現實（「骯臟」的數據，外部系統的滯後），整齊地回避。

按層排列的度量

圖層	度量標準
客戶端/邊緣	DNS p95, TLS handshake p95, TTFB, HTTP/2/3 доля
網絡	RTT/loss/jitter, ECN CE, Goodput, PPS/CPS
TLS/Proxy	handshakes/s, resumption rate, cipher mix
應用程序	p50/95/99, 5xx/429, GC pauses, threads, queues
高速緩存	hit-ratio by layer, eviction, hot-keys
DB	QPS，p95查詢，鎖定，buffer/cache命中，WAL/fsync
光盤	IOPS, latency, 4k/64k, read/write mix, fsync cost
GPU/ML	throughput (samples/s), latency, mem BW, CUDA/ROCm util

測試模板和命令

網絡（TCP/UDP）：

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

HTTP服務器（穩定負載,wrk2）：

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

開放模型（k6，arrival-rate）：

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'] }
};

光盤（fio, 4k random read）：

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

DB（sysbench+PostgreSQL示例想法）：

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

內存/CPU（Linux perf+stress-ng）：

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

統計和有效性

重播：最少10次運行，不包括outliers（粗略地說：中位數/MAD）。
置信區間：p95/p99和平均值為95％的CI。
效果-規模：相對變化及其CI（例如，− 12% ［− 9%；− 15%］）。
實際意義：以+30％CPU的價格將p95減少10％-值得嗎？
圖形：violin/ECDF用於分布，「飽和曲線」（RPS→latency）。

瓶頸分析與定位

CPU: `perf`, `async-profiler`, eBPF/pyroscope;前後的flamegraph。
Alloc/GC：運行時配置文件（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.

緩存：頂部鑰匙，TTL，事件原因。

報告和制品

要記錄的內容：

git SHA法案，編譯/優化標誌。
內核/網絡Configs（sysctl），驅動程序版本/NIC/firmware。
拓撲（vCPU/NUMA/HT），governor，溫度/頻率。
數據：大小，基數，分布。
發布內容：表p50/p95/p99,錯誤/秒,throughput,資源（CPU/RAM/IO）, CI。
工件：運行腳本，圖形，flamegraph，原始JSON/CSV結果，環境協議。

公平比較（公平基準）

相同的限制器（conn pool，keepalive，TLS鏈，OCSP stapling）。
商定的Taymauts/Retrai和HTTP版本（h2/h3）。
溫度平衡：加熱至平衡（無渦輪增壓效應）。
公平的緩存：無論是「冷」還是「溫暖」。
網絡對稱性：相同的路由/MTU/ECN/AQM。
時間預算：DNS/TLS/connect-以相同的方式明確或排除。

反模式

一次運行→「輸出」。
在單個系列中混合模式（部分寒冷，部分溫暖）。
封閉模型而不是開放給Internet負載的模型→錯誤的「可持續性」。
「RPS」 →下落不明的retrai以雙倍和級聯5xx的價格上漲。
在不同的鐵/核/能源化學上進行比較。
缺乏分析→「盲目」優化。
使用GC/heap進行遊戲，而無需分析輪廓→尾巴回歸。

實用食譜

最低基準-pipline步驟：

1.固定環境（腳本'env_capture。sh`).

2.加熱（5-10分鐘）,固定頻率/溫度。

3.進行N短重播+1長運行。

4.在高峰時刪除配置文件（CPU/alloc/IO）。

5.計算CI/圖形，收集文物。

6.決定：接受/拒絕假設，形成下一個步驟。

容量曲線（容量曲線）：

RPS步驟（10％的步驟）→固定p95/錯誤 →我們發現「膝蓋」。
我們建立一個RPS→latency和RPS→CPU的時間表：我們看到邊界和進一步利息的成本。

iGaming/fintech的細節

毫秒成本：以$-effect （轉換/流出/PSP限制）對改進進行排名。
高峰（比賽/錦標賽）：帶有TLS/CDN/緩存預熱的 spike+plateau基準。
付款/PSP：通過沙盒限制，等效性和降解反應來衡量端到端；使用代理指標捕獲時間到錢包。
Antifrod/bot過濾器：在宏基準中包含規則配置文件（false-positive-rate, latency addition）。
領導者/頭獎：測試熱鍵/排名、鎖定、原子性。

基準清單

假設/指標/成功標準。
變量控制（電源/NUMA/IRQ/網絡/緩存）。
運行計劃（復制件，持續時間，加熱）。
分開「寒冷/溫暖」模式。
已啟用性能分析（CPU/alloc/IO/DB）。
統計：CI，重要性測試，圖形。
存儲庫中的文物和repro腳本（用於展位的IaC）。
報告「改進成本」和建議。
優化後轉發（regression perf）。

迷你報告（模板）

目的：將p95 API減少15%,不增加CPU> 10%。
方法：A/B，k6開放模型1k rps，10 × 3運行，warm cache。
小計：p95 − 12% ［− 9%； − 15%］，CPU+6%，5xx不變。
Flamegraph：↓ JSON序列化（− CPU的30％），瓶頸轉移到DB。
解決方案：采用優化；下一步是爭奪DB請求。
工件：圖形，配置文件，configs，原始JSON。

底線

良好的基準測試是一種嚴格的方法+誠實的比較+統計有效性+分析+可重復性。設定假設，控制環境，計算置信間隔，發布工件，並決定改進的成本。因此，您不會在演示文稿中獲得一個美麗的數字，而是平臺速度和可預測性的實際增長。