本页目录
跑出一个数字，不等于得到一个结论
第 12 章先拦住 benchmark 里最危险的误会：数字出来了，就以为结论也出来了。
benchmark 最会骗人的地方，不是不会跑，而是特别容易跑出一个“看起来很像答案”的数字。
先把实验可信度拆开
一个结果能不能拿去做工程决策，至少要过这几关：
- 工作负载像不像真实场景
- 变量有没有控制住
- 预热和稳态有没有分开
- 不同轮次能不能比较
- 平均值、尾延时、吞吐和资源代价有没有一起看
只过了一两关，结果都还不稳。
别拿一次跑快了 20% 就宣布优化成功
最常见的错法有四种：
- 只跑一次，就开始下结论
- 测的是 A，报告里却说成 B
- 只看平均值，不看尾延时和资源代价
- 微基准跑得很好，就直接外推到真实系统
这些错法都在把“实验结果”夸大成“工程现实”。
什么时候一个 benchmark 才更可信
下面这些条件同时成立时，结果才更值得信：
- 工作负载代表性站得住
- 实验变量控制得住
- 多轮结果稳定，不只是单次好运气
- 结果变化和资源代价能一起解释
- 换一个相近场景后，结论不会立刻翻车
少了其中几项，就先把结果当线索。
一个最典型的错法：优化前后差了 20%，就宣布优化成功
现场里很常见：某次改动后数字提升了 20%，于是报告里开始写“性能优化完成”。
但这个结论里可能还缺很多东西：
- 工作负载是不是偏了
- 预热是不是没跑稳
- 尾延时是不是反而更差了
- CPU、内存、I/O 代价是不是变高了
如果这些都没补，那个 20% 很可能只是局部数字，不是工程答案。
先把实验条件、结果和外推边界分开记
先写一张 benchmark 检查表
每次实验前先过这 5 项：
- 工作负载是否代表真实场景。
- 变量是否控制住。
- 预热和正式采样是否分开。
- 多轮结果是否稳定。
- 吞吐、尾延时和资源代价是否一起记录。
结果一好看，先补反向检查
一旦看到“明显提升”，先补：
- 反向对照
- 多轮重复
- 资源代价
- 尾延时变化
先防止自己被好看的数字骗了。
跑出分数不等于测试结束，真正稳的做法是“边跑边看”。benchmark 在跑的时候，底层观测也要同时挂着；如果你没法证明目标系统真的被推到了极限，那很可能只是跑分工具自己的单线程瓶颈先到了头。
微基准和真实系统分开写
以后做报告时，把“微基准结果”和“真实场景结果”分成两栏写，不要混成一个结论。
漂亮数字也先别急着信，最好再拿硬件天花板做一轮合理性检查。比如 IOPS 一换算成吞吐量，已经明显超出当前网卡或总线的物理带宽上限，那说明你根本没打穿设备，而是全命中了缓存；凡是打破物理常识的跑分，先按假象处理。
实验可信以后，再看 perf 该不该上
第 12 章解决的是“实验结果能不能信”。第 13 章接着回到工具边界，先看 perf 该在什么条件下上场。