基准和性能比较

简短摘要

基准测试是一个实验，而不是"运行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。

底线

良好的基准测试是一种严格的方法+诚实的比较+统计有效性+分析+可重复性。设定假设，控制环境，计算置信间隔，发布工件，并决定改进的成本。因此，您不会在演示文稿中获得一个美丽的数字，而是平台速度和可预测性的实际增长。