本文是对 Brendan Gregg Evaluating the Evaluation: A Benchmarking Checklist 一文的翻译。
一位同事向我介绍了 Craig Hanson 与 Pat Crain 关于性能分析的几条箴言，这些箴言巧妙地总结了我们在性能分析和调优方面所做的大部分工作。
性能箴言
这些箴言分别是：
Don't do it
Do it, but don't do it again
Do it less
Do it later
Do it when they're not looking
Do it concurrently
Do it cheaper
这些箴言启发了我关注性能分析的另一面，即评估基准测试（benchmark）的正确性。正确的性能基准测试有助于提升项目的性能，然而不幸的是，错误的基准测试则更为常见。
我职业生涯的大部分时间都致力于正确的性能基准测试，以至于我的前雇主做的基准测试，通常在得到我的认可之后才会被最终发布。性能基准测试的正确性是如此的重要，因而我想与大家分享我是怎么确保这一点的。
或许你正在根据你需要的基准测试寻找一款符合要求的性能测试平台，抑或是你自己正在开发一款新的性能测试平台以执行相应的基准测试，无论如何，我都推荐你使用以下几个问题作为评估基准测试的清单：
Why not double?
Did it break limits?
Did it error?
Does it reproduce?
Does it matter?
Did it even happen?
基准测试评估清单
1. 为什么不能翻倍？（Why not double?）
如果你执行的一项基准测试的结果是 20k ops/sec，那么你应该问：为什么不能是 40k ops/sec？这实际上是在问：这一性能指标的限制因素是什么？区别是，前一种问法会鼓励人们去回答这一问题，而后者则更像是一个学术议题的家庭作业。在回答“为什么不能翻倍？”这个问题的过程中，人们会去找到并修复这一指标的限制因素，并最终使这一项性能指标翻倍。对于这一问题的回答，实际上还需要在基准测试的运行过程中使用其他一些可视化的工具对测试的过程进行分析（这一过程我称之为“积极的基准测试”（active benchmarking））。
2. 是否违背外部因素的限制？（Did it break limits?）
这实际上是检查你做的基准测试是否合理。我看到很多基准测试的结果实际上极大地违背了网络带宽的物理限制（其违背的程度甚至达到了10倍的网络带宽）。网络、PCIe 总线、CPU 互连总线、内存总线、以及存储设备（无论是IO通量还是IOPS），这些在性能上都存在物理限制，其中网络是最易察觉的。在某些情况下，（一项测试本机与远端数据通信性能的）基准测试的结果可能会超过网络带宽的上限，因为这些基准测试是从本地的内存缓存中读取数据，而不是远端服务器。如果你要测试，在固定数据包大小的情况下数据的传输速率，你可以先估算测试需要的最小数据通量，然后与网络链路的带宽进行比较。
3. 测试过程中有发生异常吗？（Did it error?）
测试过程中异常行为的占比是多少？0%，1%，还是 100%？基准测试的配置可能在一开始就是错误的，或者在压力测试中系统更容易发生异常行为。异常行为有别于普通的正常行为，因而异常行为的百分比很高时，测试结果的可信度就会大打折扣。如果你查看测试结果的习惯是，在冗长的测试报告中只关注数据的通量与延时，或者是使用 shell 脚本解析其中的某些指标，那么你就很容易缺失测试报告中的很多信息，例如异常行为的百分比。
4. 会复现吗？（Does it reproduce?）
如果同一个基准测试重复运行 10 次，那么测试结果的一致性如何？有很多因素（例如缓存、turbo boost 技术等），甚至是一些轻微的变化（例如系统的 cron 任务、垃圾回收等），都会导致单次测试结果的扰动。感知系统方面细微变化的一种方法是使用系统的 load 指标：在 load 指标变为 "0.00, 0.00, 0.00" 之后再开始你的基准测试。如果这一指标迟迟不能达到 “0.00, 0.00, 0.00”，那么你就需要进行 debug，找到其中的原因并解决掉。
5. 这真的重要吗？（Does it matter?）
如果我告诉你一辆汽车的时速达到 7000 mph 时它的轮子会脱离车体，而另一辆汽车的时速达到 9000 mph 时才会这样，那么这个因素会影响你的购买决策吗？并不大会。但是我却看到很多性能测试的平台，会以一种现实中并不会有的强度对某个系统组件进行测试，只是为了在数据上打败竞争对手。很多傻瓜式的测试平台基本上全是这样，这其实充满了误导性。因而你需要问你自己：这项基准测试在现实生活中真的重要吗？
6. 这真的发生过吗？（Did it even happen?）
曾经有一位客户反馈，某项基准测试测到的延时不可思议的高：每个请求的延时都达到了 1s。我的同事开始使用数据包探测工具对客户使用的机器进行检查，以验证服务器发出的数据包是否真的花了那么长的时间才到达客户的机器。结果我的同事没有看到任何的数据包！客户机器上的防火墙隔绝了一切——而测试报告中的延时只是测试软件的超时时长。因而警惕那些在基准测试实际并没有运行的情况下，由于错误配置而导致测试软件返回错误结果的情况。
我希望以上这些方法论能对你有所帮助，同时也欢迎转发给其他任何需要执行或评估基准测试的人。