benchmark-checklist

基准测试检查清单

在给出性能数据时使用此清单：例如 PR 的前后对比、性能回退声明、爬坡测试工具，或库与配置选型。每个问题都要用运行结果作为证据作答，而不是猜测代码的表现。

如果用户只想要大致估算，运行一次就够了。仍要检查问题 4 和 7，并说明只运行了一次。除非运行结果看起来不对，否则其余问题可以跳过。比较不同选项时，绝不能只给大致估算。

运行前

• 写下你预计会给出的结论，用你最终会发布的措辞表述（“在 60k 行数据集上，导出的 p50 快了 30%”）。这些问题就是用来检验这句话的。
• 阅读测量脚本，记下它计时、计数和忽略了什么。
• 用 uptime 检查负载均值，用 nproc 检查核心数。如果机器正忙，查明正在运行什么。如果无法停止这些进程，就交替运行两边，使它们受到相同噪声的影响，并在报告中说明这一点。

问题

1. 为什么没有快一倍？ 找出限制因素。在不纳入报告的一次运行中进行性能分析，因为性能分析器和跟踪器会拖慢工作。使用每个进程的 CPU 使用情况（top、pidstat）、运行时性能分析器（node --cpu-prof、py-spy、perf）、I/O 等待时间和系统调用次数（Linux 上使用 strace -c），然后将热点对应到源代码。也要关注负载生成器：如果它先达到饱和，你测到的就是负载生成器的性能。如果改动没有影响数据，就能由限制因素解释原因；因此，在称改动无用之前，先找出限制因素。
2. 调优了吗？ 按生产环境的运行方式运行两边：使用发布构建、生产环境标志和环境变量、批处理与事务设置、连接池，以及生产环境实际使用的缓存冷热状态；版本和数据也要相同。如果一边使用默认设置，你比较的是配置，而不是实现。若限制因素是某项设置（每行提交一次、调试构建、缺少索引），说明那一边尚未调优。选出胜者之前，先调优并重新测量。如果无法调优，就不要根据这次运行选出胜者。用户正在选择要采用的方案时，将结论范围缩小到当前交付的代码并不能解决问题，因为他们采用的是方案，而不是今天的设置。
3. 是否突破了限制？ 做好计算。将每秒处理的字节数与磁盘和网络带宽比较，将每秒操作数乘以单次操作成本后与核心数比较，并将节省的时间与改动部分所占用的时间比较。移除一个占运行时间 10% 的部分，最多只能让运行快约 11%。如果结果超过了限制，测到的就不是实际工作，而可能是缓存、空操作或错误。
4. 是否出错？ 统计失败和非成功响应，并检查输出是否正确，而不只是确认输出存在。拒绝通常很快，而超时和重试则很慢。如果脚本没有统计错误，就添加错误计数。
5. 结果能否复现？ 每边至少运行 5 次，并交替运行（A、B、A、B，以此类推），避免预热、延迟初始化、缓存和漂移偏向任何一边。报告中位数和范围。差距小于多次运行间的波动，就没有可测出的差异。结果接近时，使用秩和检验或测试工具自身的统计方法。
6. 这有实际影响吗？ 对于任何微基准结果，都要测量用户等待的端到端路径，并使用实际的数据量和并发数，同时报告微基准结果占整体的比例。一个辅助函数若只占请求的 1%，无论它变得多快，最多也只能让请求快 1%。
7. 实际运行了吗？ 确认工作是在计时区间内完成的：请求到达了服务端、行已写入、字节已读取，而且代码使用了结果。惰性代码（无人迭代的生成器、无人等待的 Promise、可能被 JIT 丢弃的结果）和超时，都会产生实际上并未完成工作的数据。

报告

• 开头先给出结论：更快、更慢、没有可测出的差异，或无法得出结论。
• 给出数值及其单位、运行次数、范围和瓶颈。例如：“p50 为 41 ms → 33 ms，每侧运行 7 次的中位数；运行后的范围为 32 至 35 ms，瓶颈是单核上的 JSON 解析。”
• 如果声称存在差异，却无法指出瓶颈；某一侧未经过调优；或者无法核查问题 4 和 7，则应判定为无法得出结论。说明缺失的信息。
• 根据 Opening a PR 操作手册，PR 正文只保留一个主要数值。将运行次数、范围和瓶颈证据放在关联的产物或说明文件中。

其他性能材料

• 在 Perf issue 操作手册据此制定计划之前，先核验其中的基线；之后也要核验每个数值。
• 在 Hillclimb 操作手册的测试框架冻结之前，先核验该框架。冻结后的框架会输出错误数和工作量，因此每次决定保留还是回退时，都可以顺带核查问题 4 和 7。