基准测试（Benchmarks）不必消亡

重点摘要

• 基准测试帮助社区把他们对用户行为的理解编码
• 所有基准测试面对愚弄和作弊都会显得不堪一击
• 跟踪和性能分析可以替代测试中老旧过时的用户行为模型
• 没有可以在不同项目间共享跟踪数据的常用工具
• 测试能够作为性能退化测试的一部分永远存在下去

Chromium 项目近期宣布他们将要弃用一个传统的 JavaScript 基准测试，Octane，主张通过跟踪和性能分析收集真实场景下的性能测量数据来驱动性能提升。这种性能指标，是通过对用户的跟踪和分析收集而来的。

对于弃用 Octane，他们给出的理由是，使用传统的基准测试测出的 JavaScript 性能表现已经到了稳定期，而且最终，开发者总会找到愚弄这些基准测试的方法。

不过，尚在快速演进 JavaScript 社区之外的跟踪和是否就是性能工程的未来呢？是否一切基准测试都有保质期呢？

基准测试

所有优秀的基准测试都在模拟真实世界的工作负荷。它们内置有对诸如执行时间、延迟和吞吐量、以及每秒操作次数等指标的测量能力，这种测量能力能让开发者了解他们软件的表现。

本质上说，基准测试的目的是允许用户在不同软件版本和配置之间进行比较。以完全相同的工作负荷排除掉其他因素，从而能够单独比较代码上的区别。

拥有一个封装好的的工作负荷对于软件优化工作的编写和测试是无价之宝，因为它能让开发者感知到他们所做的改变对用户体验的影响。基准测试是仲裁者。开发者们判断自己所做的改变对性能表现的影响是好是坏，还有最终，对用户的影响是好是坏。基准测试结果上 15% 的提升，可能转化为网页加载时间上 25 毫秒的缩短。

很多备受欢迎的项目就是这样完成性能优化的：选择一个基准测试工具然后开始优化那些被历经的代码路径，直到性能得到显著提升。如果没有现有的基准测试工具可用，有些项目组甚至会自行编写基准测试工具。

用人工或综合的方式测试某个特定的部件的基准测试，被称为微基准测试（Micro-Benchmark）。微基准测试在一些方面非常有用，比如理解软件将来会如何规模化，或者了解某个部件的绝对最高性能表现，即使如今已经不可能让该部件达到最大负载。

当使用全面基准测试过于麻烦的时候，使用微基准测试对于指导软件优化是有帮助的。举一个例子，当你需要对一个没有开放 API，且需要被直接访问的缓存层进行性能提升的时候。又或者，当一个开发者想要重现一个很难触发的性能问题的时候。

微基准测试有一个难以编写正确的坏名声，然而也存在着很多他们被成功用来获得性能增益的例子。

基准测试不仅对提升性能有帮助，他们也可以被用做退化测试的基准，以保证即使代码发生变化，性能表现也可以保持稳定。考虑到性能表现不像正常 / 异常这种二元状态，不能明显的观测到是否出现倒退现象，因此系统化的性能退化跟踪对于成熟的项目成熟的项目非常重要。

也许最重要的一点是，发布精心设计的基准测试可以整合全社区对有趣的工作负载和用户行为的理解。基准测试可以指导所有开发者（特别是新来的那些）去提高那些最重要的代码，由于最佳的优化，就是找出那些普遍存在的情形，并为之做出调整。

然而，如同 Google Chromium 团队指出的那样，基准测试存在着很多的缺点。

如果一个基准测试不再能够代表项目相关的工作负荷，或者更糟，它从来不能，那么那些以基准测试有效为前提编写的代码，将不得不被重写。这些之前编写的代码很可能是对开发时间的巨大浪费。

有的时候，你最好的选择是从头重写一个全新的基准测试，而不是更新已有的那个。

但是即使你的基准测试可以准确重现目前的用户行为，它的配置信息也可能会复杂到让很多人无法正确使用。基准测试越复杂，出现这种情况风险越大。参数可以被无脑的复制黏贴，极少甚至完全不考虑这些配置参数对目前被测的软件是否有意义。

并不是所有人在运行基准测试时都怀着最好的出发点，有些人会有意的尝试利用每一个漏洞来获得好处。有些基准测试一直致力于通过限定允许标志的方式来阻止编译器过度的优化代码。深度优化会让编译器消除或简化生成的代码并违背了基准测试的本意。

当所做的一切都纯粹是为了更好的测试分数而非用户时，这中行为被称作愚弄测试（Gaming the benchmark）或者针对测试的优化，这种优化被称作 “基准测试专用优化”。Chrome V8 JavaScript 引擎包含着一个 SunSpider 测试的专用优化。

“V8 使用一个相对简单的技巧：既然每个 SunSpider 测试都在一个新的 <iframe> 中运行，<iframe> 又对应着 V8 中的新的原生上下文。我们只检测 <iframe> 快速的创建和清除（所有单个 SunSpider 测试都只需要小于 50ms 的时间），而那种情况下，我们会在 <iframe> 的清除和创建之间执行一个垃圾回收，以保证在真正运行测试的时候我们不会触发垃圾回收过程。”——Benedikt Meurer

跟踪和性能分析

历史上，跟踪和性能分析分别要求不同的工具，但是现在很多项目包含器来帮助开发者理解运行时行为。这些器不仅会提供很多细节，而且他们往往很轻量级，所以可以在产品中启用。

基准测试所基于的工作负载场景不需时间推移而发生变化。想要升级这些负荷场景往往需要发布一个新的版本，而这可能会是件非常痛苦的事情，因为不可避免会有人仍然运行着旧版本而非最新的代码。如果你控制着平台，发布升级会很容易。然而如同数十年桌面软件的经验教给我们的那样，让终端用户安装补丁包会是十分惨痛的体验。

通过跟踪和性能分析从用户那里收集数据可以在这里提供帮助。它让开发者完全不必再对用户行为建模了，因为数据本身就描绘了用户行为。这些数据总是能够提供一个准确地画面，描述着在收集数据那一刻用户是怎样使用你的产品的。当这些数据变得老旧过时的时候，你仅需收集新的数据即可。

随着持续集成 / 部署变得随处可见，代码几乎是不断在改变着，任何来自上周的用户工作负载模型在今天很有可能已经过时了。

跟踪数据并不仅仅是更具有时效性，他还给开发者一个更全面的视角，因为状态变化的每一个细节都可以被捕捉到。这让性能表现的回溯分析变成了可能并且对了解是什么事件造成了性能骤降有所帮助。在记录经常发生的性能问题时，跟踪可能会是上帝的恩惠。

避免使用基准测试从本质上根除了愚弄行为。唯一重要的性能表现是现实世界中用户的体验。对于软件团队来说，作弊已经不再可能，因为所做的所有优化都是为了提升用户体验的，这一点对大家来说都是公平的。你再也不用追求基准测试结果了，你的目标是用户满意度。

最后一点，在设计商业敏感信息的情况下，跟踪允许开发者在不了解或不关注用户实际工作方式的同时，记录系统底层的细节，并做出优化设计。

但是，跟踪的一些特性虽然对开发者充满吸引力，对更高层次的社区却有着不好的影响。

把跟踪数据和生成跟踪数据的项目捆绑在一起，甚至更糟，把它在公司内部私有化，导致其他开发者没有办法在他人的工作上继续开发，而且每个项目必须从头开始理解性能表现。使用跟踪时，只有提前获取数据，开发者才能改进他们的软件。而使用传统的测试时，一旦设计并编写完毕，该测试可以无限制的用来调整和优化任何软件项目。

另外，数据的来源是非常重要的。我们该平等对待所有的用户吗？哪一个工作负载在六个月以后仍然重要呢？编写基准测试会迫使你提前决定好这些事情。

很少有软件社区做好了用跟踪和和性能分析替换基准测试的准备。到达那个阶段需要数年的工作，和开发技巧的根本转变，要拥有能捕捉，存储和分析这些数据的开发技巧。至少，需要能在不同的项目之间分享数据的工具。

是否所有基准测试都有保质期呢？

这个世界上有很多基准测试。有些已经不再有价值并且已经退休，还有个别的被新的测试替代了。Chromium 团队宣称 Octane 基准测试已经到了收益递减的阶段，但是所有基准测试注定最终要被淘汰吗？

Linux 内核社区仍在运行 90 年代和 2000 年早期开发的操作系统基准测试。因为 POSIX API 并没有经历大幅的变化，旧的基准测试不仅仅能正常运行，它还仍然可以提供一个真实的应用工作负荷。这些还没考虑到新内核平均会发布由 1,700 个开发者贡献的超过 12,000 补丁这一事实。

SPEC CPU2006 基准测试自从 2006 年以来就发挥了作用并仍在使用。但是没有持续更新的基准测试是不可能存活下去的，这些更新可能是为了对抗作弊，修改 BUG 或添加新特性，而 SPEC CPU2006 自从第一次发布以来也已经有了几次更新。这些更新的确需要来自基准测试的作者和社区的支持，他们必须想让基准测试活下去，而且愿意去维护它。

所以看起来并不是所有测试最终都会变得没有价值。只要它们提供具有代表性的工作负载，它们就将继续被使用，即使不是用于新的优化，还至少能用于性能回归测试。

结论

性能测试可以整合整个社区对于典型用户习惯的理解。它们能独立运行的特性能吸引任何项目去使用它们完成性能回归测试和性能提升，而不用花费成本从零开始分析用户行为。

Chromiun 团队想要继续为 JavaScript 的性能创造新纪录是一条令人兴奋的消息。然而在没有替代品的情况下弃用 Octane 测试，让其他项目优化它们 JavaScript 引擎的工作变得更加困难。使用跟踪和性能分析而非基准测试引起了关于数据来源和缺乏共享工具的问题。

过期的基准测试是一个问题，但是问题的解决方案应该是“更好的基准测试”，而非“不用基准测试”。我们需要更好的教育和鼓励人们编写基准测试，而且要纠正它们难以编写、有误导性、或者纯粹不能用的污名。

想判断这一切是否会成为一个潮流的起点，现在还为时过早。JavaScript 社区一直以发展迅速而闻名。但我们至少应当继续着关于基准测试的优缺点的讨论，并感激着它迄今为止帮助我们达到的性能表现。

基准测试可能还没有消亡，但是它们需要一切我们能提供的支持。

关于作者

Matt Fleming 是 SUSE 的高级工程师和一个自由撰稿人。Twitter：@fleming_matt

查看英文原文： Benchmarks Don't Have to Die

感谢冬雨对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。