12 Benchmarking

基准测试以受控方式测试性能，使得可以比较选择并理解性能限制——在其在生产环境中遇到之前。这些限制可能是系统资源、虚拟化环境（云计算）中的软件限制，或者目标应用程序中的限制。之前的章节已经探讨了这些组件，描述了存在的限制类型以及用于分析它们的工具。
之前的章节还介绍了微基准测试的工具，这些工具使用简单的人工工作负载来研究限制。其他类型的基准测试包括客户工作负载模拟，试图复制客户使用模式，以及追踪重放。无论你使用哪种类型，都很重要分析基准测试，以便确认正在测量什么。基准测试只告诉你系统可以多快地运行基准测试；你需要理解结果，并确定它如何适用于你的环境。
本章讨论了基准测试的一般情况，提供了建议和方法，帮助你避免常见错误并准确测试你的系统。当你需要解释他人的结果时，包括供应商和行业基准测试，这也是有用的背景知识。
12.1 Background
本节描述了基准测试活动和有效的基准测试，并总结了常见的错误，称之为“基准测试的罪过”。
12.1.1 Activities
基准测试可以出于以下目的进行：
系统设计：比较不同系统、系统组件或应用程序。对于商业产品，基准测试可以提供数据，帮助做出购买决策，特别是对可用选项的价格/性能比进行比较。在某些情况下，可以使用已发布的行业基准测试结果，这样就避免了客户自己执行基准测试的需要。
调优：测试可调参数和配置选项，以确定哪些值得进一步在生产工作负载中进行调查。
开发：用于产品开发过程中的非回归测试和限制调查。非回归测试可以是定期运行的自动性能测试集，以便及早发现任何性能回归，并迅速将其匹配到产品更改。对于限制调查，基准测试可以在开发过程中驱动产品达到其极限，以确定最好投入工程努力来改善产品性能的地方。
容量规划：确定容量规划的系统和应用程序限制，可以为性能建模提供数据，也可以直接找到容量限制。
故障排除：验证组件是否仍然能够以最大性能运行，例如，在主机之间测试最大网络吞吐量，以检查是否可能存在网络问题。
营销：确定产品的最大性能供营销使用（也称为基准营销）。
在企业环境中，在投资昂贵硬件之前进行基准测试可能是一个重要的验证概念的练习，并且可能是一个持续数周的过程。这包括运输、架设和连接系统的时间，然后在测试之前安装操作系统。
在云计算环境中，资源可以根据需求提供，无需对硬件进行昂贵的初始投资。但是，选择使用哪种应用程序编程语言、哪种数据库、Web 服务器和负载均衡器时，仍然需要进行一些投资。其中一些选择未来可能很难更改。基准测试可以用来调查这些选择在需要时的扩展能力。云计算模型也使基准测试变得容易：可以在几分钟内创建一个大型环境，用于进行基准测试，然后销毁，成本非常低。
12.1.2 Effective Benchmarking
基准测试出人意料地难以做到完美，存在许多错误和疏忽的机会。正如《一个关于文件系统和存储基准测试的九年研究》[Traeger 08]一文所总结的那样：
在这篇文章中，我们调查了106篇近期论文中的415个文件系统和存储基准测试。我们发现，大多数流行的基准测试存在缺陷，许多研究论文未能清楚地指示真实性能。
该论文还提出了一些建议；特别是，基准评估应该解释测试了什么以及为什么测试这些内容，并且应该对系统的预期行为进行一些分析。
好的基准测试的本质也已经被总结为 [Smaalders 06]：
可重复：以便进行比较
可观察：以便分析和理解性能
可移植：以允许在竞争对手和不同产品发布版本之间进行基准测试
易于呈现：以便每个人都能理解结果
真实可信：以便测量反映客户经历的现实
可运行：以便开发人员可以快速测试变更
在比较不同系统并打算购买时，还必须添加另一个特征：价格/性能比。价格可以量化为设备的五年资本成本[Anon 85]。
有效的基准测试还涉及如何应用基准测试：分析和得出结论。
基准测试分析
在使用基准测试时，您需要了解以下内容：
正在测试的是什么
限制因素是什么
可能影响结果的任何干扰
可以从结果中得出什么结论
这些需求需要深入了解基准软件的运行原理，系统的响应方式以及结果与目标环境的关系。
有了基准测试工具和运行该工具的系统的访问权限，最好通过性能分析来满足这些需求，而基准测试正在运行时进行。一个常见的错误是让初级员工执行基准测试，然后在基准测试完成后请性能专家解释结果。最好在进行基准测试时就让性能专家参与进来，这样他们就可以在系统仍在运行时分析系统。这可能包括深入分析以解释和量化限制因素。
以下是一个有趣的分析示例：
作为研究结果TCP/IP实现性能的实验，我们在不同机器上的两个用户进程之间传输了4兆字节的数据。传输被分成1024字节的记录，并封装在1068字节的以太网数据包中。通过TCP/IP从我们的11/750发送数据到我们的11/780花费了28秒。这包括设置和拆除连接所需的所有时间，用户之间的吞吐量为1.2兆比特/秒。在此期间，11/750的CPU被完全占用，但11/780有大约30%的空闲时间。在系统中处理数据的时间分散在以太网处理（20%）、IP数据包处理（10%）、TCP处理（30%）、校验和（25%）和用户系统调用处理（15%）之间，没有任何一个部分在系统中占据主导地位。
这描述了检查限制因素（“11/750的CPU被完全占用”），然后解释了导致这些因素的内核组件的细节。值得一提的是，即使使用了高级工具如DTrace，能够执行这种分析并如此清晰地总结内核时间在今天仍然是一种不寻常的技能。这段引用来自1981年比尔·乔伊（Bill Joy）在开发原始的BSD TCP/IP堆栈时！[1]
除了使用特定的基准测试工具外，您可能会发现开发自己的定制基准测试软件，或者至少是定制负载生成器更加有效。这些可以保持简洁，只关注您测试所需的内容，使其快速分析和调试。
在某些情况下，您可能无法访问基准测试工具或系统，比如在阅读他人的基准测试结果时。根据可用的材料考虑前述事项，并且另外询问：系统环境是什么？它是如何配置的？您可能会获准向供应商提出这些问题。有关更多供应商问题，请参阅第12.4节“基准问题”。
12.1.3 Benchmarking Sins
以下各节提供了一个特定问题的快速检查清单，以及如何避免这些问题。第12.3节“方法论”描述了如何进行基准测试。
随意的基准测试
要做好基准测试并不是一个一劳永逸的活动。基准测试工具提供了数字，但这些数字可能不反映您的想法，因此您对它们的结论可能是错误的。
随意的基准测试：您对A进行基准测试，但实际上测量的是B，并得出您已测量了C的结论。
做好基准测试需要严谨性，以检查实际测量的内容，并理解测试了什么以形成有效的结论。
例如，许多工具声称或暗示它们测量磁盘性能，但实际上测试的是文件系统性能。这两者之间的差异可能是数量级的，因为文件系统使用缓存和缓冲来替代磁盘I/O，而使用内存I/O。即使基准测试工具可能正常运行并测试文件系统，您对磁盘的结论也将大大不正确。
对于初学者来说，理解基准测试特别困难，因为他们无法判断数字是否可疑。如果您购买了一个将您所在房间的温度显示为1000华氏度的温度计，您会立即意识到有些不对劲。但基准测试并非如此，它产生的数字可能对您来说是陌生的。
盲目相信基准测试
也许会诱人地相信一个流行的基准测试工具是可信的，特别是如果它是开源的，并且已经存在很长时间。认为流行等于有效的误解被称为“广义论逻辑”（拉丁语意为“向人民呼吁”）。
分析您正在使用的基准测试工具是耗时的，并且需要专业知识来正确执行。对于一个流行的基准测试工具，分析它看似必须是有效的，可能会显得浪费时间。
问题甚至不一定在于基准测试软件本身——虽然错误确实会发生——而是在于对基准测试结果的解释。
没有分析的数字
提供了没有分析细节的简单基准测试结果可能表明作者缺乏经验，并且假设基准测试结果是可信的和最终的。通常，这只是调查的开始，而且结果可能是错误的或令人困惑的。
每个基准测试数字都应该附带对遇到的限制和执行的分析的描述。我用以下方式总结了这种风险：
如果您花了不到一周的时间研究基准测试结果，那么它很可能是错误的。
本书的很大一部分关注于分析性能，在基准测试期间应该进行这种分析。在没有时间进行仔细分析的情况下，将假设列出并包含在结果中是一个好主意，例如：
假设基准测试工具没有漏洞
假设磁盘I/O测试实际上测量了磁盘I/O
假设基准测试工具将磁盘I/O驱动到其预期的极限
假设这种类型的磁盘I/O对于这个应用程序是相关的
如果基准测试结果后来被认为很重要而值得花费更多精力，这就可以成为一个待办事项清单。
复杂的基准测试工具
基准测试工具的复杂性不应该阻碍基准分析。理想情况下，该程序是开源的，以便可以进行研究，并且足够简短，可以快速阅读和理解。
对于微基准测试，建议选择使用C编程语言编写的工具。对于客户端模拟基准测试，建议使用与客户端相同的编程语言，以减小差异。
常见问题之一是对基准测试工具本身进行基准测试，即所报告的结果受到基准软件本身的限制。由于需要理解和分析的代码量巨大，复杂的基准测试套件可能会使这一问题难以确定。
测试错误的内容
虽然有大量的基准测试工具可用于测试各种工作负载，但其中许多可能与目标应用程序无关。
例如，一个常见的错误是测试磁盘性能——基于磁盘基准测试工具的可用性——尽管目标环境工作负载预计完全在文件系统缓存中运行，与磁盘I/O无关。
同样，一个开发产品的工程团队可能会标准化一个特定的基准，并将所有性能努力都花在提高该基准衡量的性能上。然而，如果实际上与客户工作负载不符，则工程努力将优化错误的行为。基准测试可能曾经测试了一个适当的工作负载，但多年来没有更新，因此现在测试了错误的内容。文章《对一个基准的颂词》描述了SPEC SFS行业基准测试的一个版本，该基准测试常在2000年代引用，其基础是1986年的客户使用研究。
忽视错误
仅仅因为基准测试工具生成了一个结果，并不意味着该结果反映了一个成功的测试。一些，甚至全部，请求可能导致错误。虽然这个问题在前述错误中已经涵盖了，但这个问题特别普遍，值得特别指出。
最近对Web服务器性能进行基准测试时，我想起了这一点。进行测试的人报告说，Web服务器的平均延迟超出了他们的需求：平均超过一秒。一些快速的分析确定了出了什么问题：在测试期间，Web服务器根本没有做任何事情，因为所有请求都被防火墙阻止了。所有的请求。所显示的延迟是基准客户端超时和错误所花费的时间。
忽视差异
基准测试工具，尤其是微基准测试，通常会应用稳定和一致的工作负载，基于一系列实际特征的平均值，例如不同时间的特征或某个时间段的特征。例如，可以发现磁盘工作负载的平均读取速率为每秒500次，写入速率为每秒50次。然后，基准测试工具可能会模拟这个速率，或者模拟10:1读写比例，以便测试更高的速率。
这种方法忽视了差异：操作速率可能是可变的。操作类型也可能变化，一些类型可能会正交发生。例如，写入可能会每10秒进行一次突发操作（异步写回数据刷新），而同步读取则是稳定的。写入的突发操作可能会在生产环境中引发真正的问题，例如通过排队读取，但如果基准应用稳定的平均速率，则不会模拟这些情况。
忽视扰动
考虑到外部扰动可能影响结果。在基准测试运行期间，是否会执行定时的系统活动，例如系统备份？对于云环境，扰动可能由同一系统上的未见租户引起。
消除扰动的常见策略是延长基准测试的运行时间——从几秒钟延长到几分钟。作为一项规则，基准测试的持续时间不应短于一秒。短暂的测试可能会异常地受到设备中断（在执行中断服务程序时固定线程）、内核CPU调度决策（在迁移排队线程之前等待以保持CPU亲和性）和CPU缓存热效应的影响。尝试多次运行基准测试，并检查标准偏差。这应尽可能小，以确保可重复性。
还要收集数据，以便研究扰动（如果存在）。这可能包括收集操作延迟的分布——而不仅仅是基准测试的总运行时间——以便看到异常值并记录其详细信息。
改变多个因素
在比较两次测试的基准测试结果时，务必注意了解两者之间的所有不同因素。
例如，如果对两台主机进行网络基准测试，它们之间的网络是否完全相同？如果一台主机距离更远，位于一个速度较慢或拥塞较严重的网络上会怎样？任何此类额外因素都可能使基准测试结果失真。
在云环境中，有时会通过创建实例、测试它们，然后销毁它们来进行基准测试。这会产生许多未见因素的潜在问题：实例可能是在更快或更慢的系统上创建的，或者是在其他租户负载和争用更高的系统上创建的。建议测试多个实例并取平均值（或更好地记录分布），以避免由于测试一个异常快或慢的系统而引起的异常值。
竞争对手基准测试
您的营销部门希望有基准测试结果，展示您的产品如何击败竞争对手。我将要解释的原因通常是一个坏主意。
当客户选择一个产品时，他们不是使用它5分钟；他们会使用几个月。在此期间，他们会分析和调整产品性能，也许在最初的几周摆脱最糟糕的问题。
您没有几周时间来分析和调整竞争对手。在可用的时间内，您只能收集未调整的——因此不现实的——结果。竞争对手的客户——这次营销活动的目标——很可能会注意到您发布了未调整的结果，因此您的公司将失去对试图给他们留下印象的人的信誉。
如果您必须对竞争对手进行基准测试，您将希望花费大量时间来调整他们的产品。使用早期章节中描述的技术分析性能。还要搜索最佳实践、客户论坛和错误数据库。您甚至可能想要引入外部专业知识来调整系统。然后在最后进行公司内部的对比基准测试之前，为自己的公司做同样的努力。
友军误伤
在对自己的产品进行基准测试时，应尽一切努力确保已经测试了性能最佳的系统和配置，并且系统已经被推到了真正的极限。在发布之前与工程团队分享结果；他们可能会注意到您错过的配置项。如果您在工程团队中，要注意基准测试的努力——无论是来自您的公司还是来自签约的第三方——并帮助他们。
考虑这样的假设情况：一个工程团队努力开发了一个性能出色的产品。关键是一个新技术，他们开发了这个技术，但尚未记录。为产品发布，一个基准测试团队被要求提供数据。他们不了解新技术（没有文档），他们错误配置了它，然后他们发布了低估产品的数字。
有时系统可能已经正确配置，但只是还没有被推到极限。问一下这个基准测试的瓶颈是什么？这可能是一个物理资源，如CPU、磁盘或互连，已经被推到了100%，可以使用分析来识别。参见第12.3.2节，“主动基准测试”。
另一个友军误伤问题是基准测试较旧版本的软件，这些软件在后续版本中已经修复了性能问题，或者在可用的有限设备上进行测试，产生的结果不是最好的（这可能是公司基准测试所期望的）。
误导性基准测试
误导性基准测试结果在行业中很常见。通常情况下，这是由于对基准测试实际测量内容的信息受限，或者有意地省略了信息。通常情况下，基准测试结果在技术上是正确的，但却被误导性地呈现给客户。
考虑这样一个假设情况：一个供应商通过构建一款定制产品获得了出色的结果，但这款产品价格昂贵，实际上不会销售给实际客户。基准测试结果中未披露价格，而是侧重于非价格/性能指标。市场营销部门大量分享了基准测试结果的模糊摘要（“我们速度提升了2倍！”），将其与公司整体或产品线联系在客户的心中。这是一种省略细节以有利地误导产品的情况。虽然这可能不是欺骗——数字并非虚假——但却是通过遗漏来撒谎。
这种供应商基准测试结果可能仍然对您有用，作为性能的上限。这些数值是您不应该期望超过的值（在友军误伤的情况下除外）。
再考虑一个不同的假设情况：一个营销部门有预算用于推广活动，并希望获得一个好的基准测试结果来使用。他们请几家第三方进行基准测试，并从中挑选出最佳的结果。这些第三方不是因为他们的专业知识而被选中的；他们被选中是为了提供快速和廉价的结果。事实上，非专业知识可能被认为是有利的：结果与现实偏离得越大，越好。理想情况下，其中一家偏离的方向非常积极！
在使用供应商结果时，务必注意检查详细信息，包括测试了什么系统、使用了多少种类型的磁盘、使用了哪种配置的网络接口等。要注意的具体细节，请参阅第12.4节“基准测试问题”。
基准测试特殊优化
一种被一些人视为罪恶并因此被禁止的狡猾行为是开发基准测试特殊优化。这就是供应商研究流行或行业基准测试，然后设计产品使其得分良好，而不考虑实际客户性能的情况。这也被称为为基准测试进行优化。
基准测试特殊优化的概念始于1993年的TPC-A基准测试，如Transaction Processing Performance Council (TPC)历史页面所述：
马萨诸塞州的咨询公司Standish Group指责Oracle向其数据库软件添加了一个特殊选项（离散事务），目的只是为了增加Oracle的TPC-A结果。Standish Group声称Oracle“违反了TPC的精神”，因为离散事务选项是典型客户不会使用的东西，因此是基准测试特殊优化。Oracle强烈否认了这一指控，并表示他们在基准测试规范上严格遵循了法律，这在某种程度上是有道理的。Oracle辩称，由于TPC基准测试规范中既没有涉及基准测试特殊优化，也没有涉及TPC精神，因此指控他们违反任何规定都是不公平的。
TPC增加了反对基准测试特殊优化的条款：
所有改善基准测试结果但不改善实际性能或定价的“基准测试特殊”实施都是被禁止的。
由于TPC侧重于价格/性能，另一种夸大数字的策略是基于特殊定价——实际客户无法获得的深度折扣。就像特殊的软件更改一样，当真实客户购买系统时，结果与现实不符。TPC在其价格要求中解决了这个问题：
TPC规范要求总价格必须在与客户为配置支付的价格相差不超过2%的范围内。
虽然这些例子可能有助于解释基准测试特殊优化的概念，但TPC多年前就在其规范中对其进行了处理，您不必现在就期望出现这种情况。
作弊
基准测试的最后一个罪行是作弊：分享虚假结果。幸运的是，这要么很少见，要么根本不存在；即使在最激烈的基准测试战斗中，我也没有看到过纯粹捏造的数字被分享的情况。
12.2 Benchmarking Types
图12.1展示了基于测试工作负载的基准测试类型谱系。生产工作负载也包含在谱系中。

接下来的几节将描述三种基准测试类型：微基准测试、模拟和跟踪/重放。同时也会讨论行业标准基准测试。
12.2.1 Micro-Benchmarking
微基准测试使用人工工作负载，测试特定类型的操作，例如执行单一类型的文件系统I/O、数据库查询、CPU指令或系统调用。其优势在于简单性：减少涉及的组件数量和代码路径使得研究目标更容易，并且能够快速确定性能差异的根本原因。由于尽可能排除了其他组件的变化，测试通常也是可重复的。微基准测试通常也很快速，可以在不同系统上进行测试。并且由于它们是刻意人工制造的，因此微基准测试不容易与真实工作负载模拟混淆。
为了利用微基准测试结果，需要将其映射到目标工作负载。微基准测试可能会测试多个维度，但只有一两个可能是相关的。对目标系统的性能分析或建模可以帮助确定哪些微基准测试结果是适当的，以及适用程度。
在前几章提到的示例微基准测试工具包括，按资源类型，
- CPU：UnixBench，SysBench
- 内存I/O：lmbench（在第6章，CPU中）
- 文件系统：Bonnie，Bonnie++，SysBench，fio
- 磁盘：hdparm
- 网络：iperf
还有许多其他基准测试工具可用。但请记住[Traeger 08]的警告：“大多数流行的基准测试都存在缺陷。”
你也可以开发自己的基准测试。目标是尽可能简单，识别可以单独测试的工作负载属性。（有关此内容的更多信息，请参见第12.3.6节，自定义基准测试。）
设计示例
考虑设计一个文件系统微基准测试，以测试以下属性：顺序或随机I/O、I/O大小和方向（读取或写入）。表12.1显示了五个样本测试，用于研究这些维度，以及每个测试的原因。

可以根据需要添加更多测试。所有这些测试都会乘以两个额外的因素：
- 工作集大小：被访问数据的大小（例如，总文件大小）：
  - 远远小于主内存：以使数据完全缓存在文件系统缓存中，并可以调查文件系统软件的性能。
  - 远远大于主内存：以最小化文件系统缓存的影响，并将基准测试驱动到测试磁盘I/O。
- 线程数量：假设工作集大小较小：
  - 单线程测试文件系统性能，基于当前CPU时钟速度。
  - 多线程 - 足以饱和所有CPU - 以测试系统的最大性能：文件系统和CPU。
这些因素很快就会相乘形成一个庞大的测试矩阵。有统计分析技术可以减少所需的测试集。
创建专注于最高速度的基准测试被称为晴天性能测试。为了不忽视问题，您还希望考虑阴天性能测试，这涉及测试非理想情况，包括争用、扰动和工作负载变化。
12.2.2 Simulation
许多基准测试模拟客户应用程序工作负载（有时称为宏基准测试）。这些可能基于对生产环境的工作负载特性进行的特征化（参见第2章，方法论），以确定要模拟的特性。例如，可能会发现生产 NFS 工作负载由以下操作类型和概率组成：读取，40％；写入，7％；获取属性，19％；读取目录，1％；等等。还可以测量和模拟其他特性。
模拟可以产生类似于客户端在真实工作负载下的性能的结果，即使不是非常接近，至少也足够有用。它们可以包含许多因素，使用微基准测试进行调查将耗费大量时间。模拟还可以包括使用微基准测试时可能完全遗漏的复杂系统交互的影响。
在第6章，CPU 中介绍的 CPU 基准测试 Whetstone 和 Dhrystone 就是模拟的示例。Whetstone 是在 1972 年开发的，用于模拟当时的科学工作负载。Dhrystone，来自 1984 年，模拟了当时基于整数的工作负载。之前提到的 SPEC SFS 基准测试是另一个工作负载模拟。
工作负载模拟可以是无状态的，其中每个服务器请求与前一个请求无关。例如，之前描述的 NFS 服务器工作负载可以通过请求一系列操作来模拟，每个操作类型根据测得的概率随机选择。
模拟也可以是有状态的，其中每个请求依赖于客户端状态，至少依赖于前一个请求。可能会发现 NFS 读取和写入倾向于成组到达，这样，如果前一个操作是写入，则写入的概率要比读取时高得多。可以使用马尔可夫模型更好地模拟这样的工作负载，通过将请求表示为状态并测量状态转换的概率[Jain 91]。
模拟的一个问题是它们可能忽略方差，如第12.1.3节“基准测试的罪过”所述。客户使用模式也可能随时间而变化，需要更新和调整这些模拟以保持相关性。然而，如果已经有基于旧基准版本发布的结果，那么可能会对这种更新存在抵制，因为这些结果将不再可用于与新版本进行比较。
12.2.3 Replay
第三种基准测试类型涉及尝试重放跟踪日志到目标系统，并通过实际捕获的客户端操作来测试其性能。这听起来理想——就像在生产环境中测试一样，对吧？然而，这种方法存在问题：当服务器的特性和交付延迟发生变化时，捕获的客户端工作负载不太可能自然地对这些差异做出反应，这可能证明并不比模拟的客户端工作负载更好。当人们对此过于信任时，情况可能变得更糟。
考虑这样一个假设情景：一个客户正在考虑升级存储基础设施。当前的生产工作负载被跟踪并重放到新硬件上。不幸的是，性能变差了，销售也失去了。问题在于：跟踪/重放操作在磁盘 I/O 层面进行。旧系统使用的是 10,000 转每分钟的磁盘，而新系统使用的是转速较慢的 7,200 转每分钟的磁盘。然而，新系统提供了 16 倍于旧系统的文件系统缓存以及更快的处理器。实际生产工作负载的性能本应会得到改善，因为它主要会从缓存中返回——而重放磁盘事件并未模拟这一点。
虽然这是一个测试错误的案例，但即使使用正确级别的跟踪/重放，其他微妙的时间效应也可能会搞乱事情。与所有基准测试一样，分析和理解正在发生的事情至关重要。
12.2.4 Industry Standards
行业标准基准测试由独立组织提供，旨在创建公平且相关的基准测试。通常这些基准测试由多个微基准测试和工作负载模拟组成，这些测试都被明确定义和文档化，并且必须根据某些指导方针执行，以确保结果如预期。厂商可以参与其中（通常需要支付费用），这为厂商提供了执行基准测试的软件。他们的结果通常需要完全披露配置环境，可能会接受审计。
对于客户来说，这些基准测试可以节省大量时间，因为可能已经为各种厂商和产品提供了基准测试结果。因此，您的任务是找到与您未来或当前的生产工作负载最相似的基准测试。对于当前的工作负载，这可能是通过工作负载特征化来确定的。
工业标准基准测试的需求在 1985 年一篇题为《事务处理能力的衡量》的论文中被明确提出，该论文由吉姆·格雷（Jim Gray）等人撰写。该论文描述了衡量价格/性能比的需求，并详细介绍了供应商可以执行的三种基准测试，称为 Sort、Scan 和 DebitCredit。它还提出了基于 DebitCredit 的工业标准事务每秒（TPS）的衡量方法，类似于汽车的每加仑英里。吉姆·格雷及其工作后来鼓励了 TPC 的创建。
除了 TPS 衡量标准之外，还有其他用于相同角色的衡量标准，包括：
- MIPS：每秒百万条指令数。虽然这是一种性能衡量标准，但执行的工作取决于指令的类型，这在不同处理器架构之间可能难以比较。
- FLOPS：每秒浮点运算次数——类似于 MIPS，但用于对浮点计算密集型工作负载进行衡量。
工业基准测试通常根据基准测试衡量一个自定义指标，仅用于与自身进行比较。
TPC
TPC 是指标准性能评估公司（TPC，The Transaction Processing Performance Council），该机构创建并管理各种行业基准测试，重点关注数据库性能。其中包括：
- TPC-C：模拟完整的计算环境，其中一组用户针对数据库执行事务。
- TPC-DS：模拟决策支持系统，包括查询和数据维护。
- TPC-E：在线事务处理（OLTP）工作负载，模拟经纪公司数据库，客户生成与交易、账户查询和市场研究相关的交易。
- TPC-H：决策支持基准测试，模拟临时查询和并发数据修改。
- TPC-VMS：TPC 虚拟测量单系统允许为虚拟化数据库收集其他基准测试。TPC 的结果在网上共享，包括价格/性能比。
SPEC
SPEC 是标准性能评估公司（SPEC，The Standard Performance Evaluation Corporation），该公司开发和发布一套标准化的行业基准测试，其中包括：
- SPEC CPU2006：计算密集型工作负载的衡量标准。包括整数性能的 CINT2006 和浮点性能的 CFP2006。
- SPECjEnterprise2010：Java Enterprise Edition（Java EE）5 或更高版本应用服务器、数据库和支持基础设施的全系统性能衡量标准。
- SPECsfs2008：用于 NFS 和常见互联网文件系统（CIFS）服务器的客户端文件访问工作负载模拟。
- SPECvirt_sc2010：针对虚拟化环境，衡量虚拟化硬件、平台以及客户操作系统和应用软件的性能。SPEC 的结果在网上共享，包括系统如何进行调优以及组件列表，但通常不包括价格信息。
12.3 Methodology
这一部分介绍了进行基准测试的方法和练习，无论是微基准测试、模拟还是重播。相关主题总结在表12.2中。

12.3.1 Passive Benchmarking
这是基准测试的"点火忘记"策略——即执行基准测试然后忽略直到完成。主要目标是收集基准测试数据。这是基准测试常见的执行方式，并被描述为与主动基准测试进行比较的一种方法论。以下是一些被动基准测试的示例步骤：
1. 选择一个基准测试工具。
2. 使用各种选项运行它。
3. 制作结果的幻灯片。
4. 将幻灯片交给管理层。
此方法存在一些问题，之前已经讨论过。总结起来，结果可能是：
- 由于基准测试软件缺陷而无效。
- 受基准测试软件限制（例如，单线程）。
- 受与基准测试目标无关的组件限制（例如，拥塞的网络）。
- 受配置限制（性能特性未启用，不是最大配置）。
- 受干扰影响（不可重复）。
- 完全基准测试了错误的事物。
被动基准测试易于执行，但容易出错。如果由供应商执行，可能会产生错误的警报，浪费工程资源或导致销售损失。如果由客户执行，可能会导致后来选择产品时出现问题，影响公司的发展。
12.3.2 Active Benchmarking
通过主动基准测试，您可以在基准测试运行时分析性能，而不仅仅是在完成后使用其他工具。您可以确认基准测试是否测试了它所说的内容，并且您理解了测试内容。主动基准测试还可以识别受测试系统或基准测试本身限制的真实因素。在分享基准测试结果时，包含遇到的限制的具体细节非常有帮助。
作为额外的好处，这也是发展您的性能观测技能的好时机。理论上，您正在检查一个已知负载，并可以从这些工具中看到它的表现方式。
理想情况下，基准测试可以配置并保持在稳定状态下运行，以便可以在数小时或数天的时间段内进行分析。
举例来说，让我们看一下Bonnie++微基准测试工具的第一个测试。在其主页上描述如下：
Bonnie++是一个旨在执行一些简单的硬盘和文件系统性能测试的基准测试套件。
第一个测试是“顺序输出”和“每字符”，并且在两个不同的操作系统上执行以进行比较。
- Fedora/Linux（在KVM虚拟化下）：

- SmartOS/illumos（在操作系统虚拟化下）：

因此，SmartOS快了3.1倍。如果我们就此打住，那将是被动基准测试。
鉴于Bonnie++是一个“硬盘和文件系统性能”基准测试，我们可以从检查执行的工作负载开始。
在SmartOS上运行iostat(1M)来检查磁盘I/O：

磁盘开始处于空闲状态，然后在基准测试期间显示可变的写入吞吐量（kw/s），但远低于Bonnie++报告的K/sec结果。
在SmartOS上运行vfsstat(1M)来检查文件系统I/O（VFS级别）：

现在吞吐量与Bonnie++的结果一致。然而，IOPS并不是：vfsstat(1M)显示写入大约为每个128 K字节（kw/s / w/s），而不是“每字符”。
在SmartOS上使用truss(1)来调查对文件系统的写入（暂时忽略truss(1)的开销）：

这证实了Bonnie++执行的是128 K字节的文件系统写入。
在Fedora上使用strace(1)进行比较：

这显示Fedora执行的是4 K字节的文件系统写入，而SmartOS执行的是128 K字节的写入。
通过更多的分析（使用DTrace），发现这是系统库中putc()的缓冲，每个操作系统默认使用不同的缓冲大小。作为一个实验，将Fedora上的Bonnie++调整为使用128 K字节的缓冲（使用setbuffer()），其性能提高了18%。
主动性能分析确定了该测试执行的各种其他特征，从而更好地理解了结果。结论是，它最终受到单线程CPU速度的限制，并且85%的CPU时间花费在用户模式中。
Bonnie++并不是一个异常糟糕的基准测试工具；在许多情况下，它都为人们提供了帮助。我选择了它作为这个示例（并且还选择了其中最可疑的测试进行研究），因为它众所周知，我以前曾研究过它，而且像这样的发现并不少见。但这只是一个例子。
值得注意的是，Bonnie++的一个较新的实验版本已将“Per Chr”测试更改为实际执行1字节的文件系统I/O。对于此测试，比较不同版本的Bonnie++结果将显示显着差异。有关Bonnie++性能分析的更多信息，请参阅Roch Bourbonnais的文章“解码Bonnie++”。
12.3.3 CPU Profiling
CPU的性能分析是一种值得单独提出的方法论，因为它可能导致一些快速的发现。通常作为主动基准测试调查的一部分进行。
其目的是快速检查所有软件的运行情况，看看是否有什么有趣的发现。这也可以将研究范围缩小到最重要的软件组件：那些在基准测试中起作用的组件。
可以对用户级别和内核级别的堆栈进行性能分析。用户级CPU性能分析是在第5章“应用程序”中介绍的。两者都在第6章“CPU”中涵盖，其中包括在第6.6节“分析”中的示例，包括火焰图。
例子
在一个提议的新系统上进行了磁盘微基准测试，结果令人失望：磁盘吞吐量比旧系统更差。有人要求我找出问题所在，预期是磁盘或磁盘控制器要么不够好，要么应该升级。
我从使用USE方法（第2章“方法论”）开始，发现尽管这是基准测试的重点，但磁盘并不是很忙碌。在系统时间（内核）中有一些CPU使用率。
对于磁盘基准测试，你可能不会期望CPU成为有趣的分析对象。鉴于内核中有一些CPU使用率，我认为值得快速检查是否会出现任何有趣的情况，尽管我并不指望会有。我进行了性能分析，并生成了图12.2中显示的火焰图。

浏览堆栈帧显示，62.17%的CPU样本包含一个名为zfs_zone_io_throttle()的函数。我不需要阅读该函数的代码，因为其名称已经足够提示：一个资源控制，ZFS I/O限制，正在激活并人为地限制基准测试！这是新系统的默认设置（但不是旧系统），在进行基准测试时被忽略了。
12.3.4 USE Method
USE方法是在第2章“方法论”中介绍的，并且在研究其资源的章节中进行了描述。在基准测试期间应用USE方法可以确保找到一个限制。要么某些组件（硬件或软件）已经达到了100%的利用率，要么你没有将系统推向极限。
使用USE方法的一个例子在第12.3.2节“主动基准测试”中进行了描述，它帮助发现磁盘基准测试未按预期工作的问题。
12.3.5 Workload Characterization
工作负载特性也是在第2章“方法论”中介绍的，并在后续章节中进行了讨论。这种方法论可以用来确定给定基准测试与当前生产环境的关系有多好，方法是对生产负载进行特性化以进行比较。
12.3.6 Custom Benchmarks
对于简单的基准测试，自己编写软件可能是一个理想选择。尽量保持程序尽可能简短，以避免复杂性影响分析。C编程语言通常是一个不错的选择，因为它与实际执行的内容密切相关，尽管需要仔细考虑编译器优化如何影响代码：如果编译器认为输出未被使用且不必要计算，则可能会省略简单的基准测试例程。值得反汇编已编译的二进制文件以查看实际执行的内容。
涉及虚拟机、异步垃圾回收和动态运行时编译的语言可能更难以以可靠的精度进行调试和控制。如果需要模拟使用这些语言编写的客户端软件，则可能仍然需要使用这些语言。
编写自定义基准测试还可以揭示有关目标的微妙细节，这些细
12.3.7 Ramping Load
这是一种确定系统能够处理的最大吞吐量的简单方法。它涉及逐步增加负载，并测量传递的吞吐量，直到达到极限。结果可以制成图表，显示出可扩展性概况。这个概况可以通过可视化或使用可扩展性模型（参见第2章“方法论”）进行研究。
作为示例，图12.3显示了文件系统和系统随线程数量的变化情况。每个线程对一个缓存文件执行8 K字节的随机读取，并逐个添加。

该系统的峰值达到了近50万次读取每秒。通过使用VFS级别的统计数据对结果进行了检查，确认了I/O大小为8 K字节，并且在峰值时传输速率超过3.5 GB/s。
这个测试的负载生成器是用Perl编写的，而且足够简短，可以完全作为示例包含进来：

这使用sysread()直接调用read()系统调用来避免缓冲。这是为了微基准测试一个NFS服务器而编写的，并且从一组客户端并行执行，每个客户端在一个NFS挂载的文件上执行随机读取。微基准测试的结果（每秒读取次数）是在NFS服务器上使用nfsstat(1M)和其他工具进行测量的。所使用的文件数量及其组合大小受到控制（这形成了工作集大小），以便某些测试可以完全从缓存返回，而其他测试则从磁盘返回。（参见第12.2.1节“微基准测试”中的设计示例。）逐个递增在客户端农场上执行的实例数量，以逐步增加负载直到达到极限。这也被制成图表以研究可扩展性概况，以及资源利用（USE方法），确认资源已经耗尽。在这种情况下，是CPU资源，这启动了另一项调查以进一步提高性能。我使用这个程序和这种方法来找出Oracle ZFS存储设备（正式称为Sun ZFS存储设备[10]）的限制。这些限制被用作官方结果，据我们所知创下了世界记录。我还有一个类似的用C语言编写的软件集，但在这种情况下并不需要：我有大量的客户端CPU，而且虽然转换到C语言减少了它们的利用率，但对于结果来说没有影响，因为目标上达到了同样的瓶颈。还尝试了其他更复杂的基准测试，以及其他语言，但它们都无法改进这些结果。在采用这种方法时，除了吞吐量外，还要测量延迟，特别是延迟分布。一旦系统接近其极限，排队延迟可能变得显著，导致延迟增加。如果负载推得太高，延迟可能会变得如此之高，以至于不再合理地考虑结果是否有效。问自己传递的延迟是否对客户可接受。例如：您使用一个大型的客户端数组来驱动一个目标系统达到990,000 IOPS，它的平均I/O延迟为5毫秒。您确实希望它突破100万IOPS，但系统已经达到饱和。通过添加更多的客户端，您设法突破了100万IOPS；然而，所有操作现在都被大量排队，平均延迟超过50毫秒（这是不可接受的）！您会向营销部门提供哪个结果？（答案：990,000 IOPS。）
12.3.8 Sanity Check
这是一个检查基准测试结果的练习，通过调查是否存在任何不合理的特征来进行。这包括检查结果是否需要某些组件超出其已知限制，例如网络带宽、控制器带宽、互连带宽或磁盘IOPS。如果超出了任何限制，值得进行更详细的调查。在大多数情况下，这种练习最终会发现基准测试结果是虚假的。
以下是一个示例：对一个NFS服务器进行基准测试，使用8 K字节读取，报告交付50,000 IOPS。它使用单个1 Gbit/s以太网端口连接到网络。驱动50,000 IOPS x 8 K字节所需的网络吞吐量为400,000 K字节/秒，加上协议头。这超过了已知的1 Gbit/s限制，超过3.2 Gbit/s。显然有些不对劲！
这样的结果通常意味着基准测试已经测试了客户端缓存，并没有将整个工作负载驱动到NFS服务器上。
我曾使用这种计算方法识别了许多虚假的基准测试，其中包括以下吞吐量超过1 Gbit/s接口的情况：
- 120兆字节/秒
- 200兆字节/秒
- 350兆字节/秒
- 800兆字节/秒
- 1.15吉字节/秒
这些都是单向吞吐量。120兆字节/秒的结果可能是正常的，因为1 Gbit/s接口的速度应该达到大约119兆字节/秒。200兆字节/秒的结果只有在两个方向上都有大量流量并且求和后才可能出现；然而，这些是单向结果。350兆字节/秒及以上的结果都是虚假的。
当你收到一个基准测试结果来检查时，看看你可以对提供的数字进行哪些简单的求和来发现这种限制。
如果你可以访问系统，可能可以通过构建新的观察或实验来进一步测试结果。这可以遵循科学方法：你现在正在测试的问题是基准测试结果是否有效。从这个问题中，可以提出假设和预测，然后进行验证测试。
12.3.9 Statistical Analysis
统计分析是收集和研究基准数据的过程，它遵循三个阶段：
1. 选择基准工具、其配置以及捕获系统性能指标。
2. 执行基准测试，收集大量结果和指标的数据集。
3. 进行统计分析来解释数据，生成报告。
与在基准测试运行时分析系统的主动基准测试不同，统计分析侧重于分析结果。它也与被动基准测试不同，在被动基准测试中根本不进行分析。这种方法在访问大型系统可能受到时间限制和成本限制的环境中使用。例如，可能只有一个“最大配置”系统可用，但许多团队同时希望访问以运行测试，包括：
- 销售团队：在概念验证期间，运行模拟客户负载以展示最大配置系统能够提供的内容。
- 市场营销团队：为了获得市场营销活动的最佳数据。
- 技术支持团队：调查仅在最大配置系统下严重负载时出现的病理情况。
- 工程团队：测试新功能和代码更改的性能。
- 质量团队：执行非回归测试和认证。
每个团队可能只有有限的时间在系统上运行其基准测试，但在之后分析结果的时间可能更多。
由于收集指标的成本很高，要额外努力确保它们可靠且值得信赖，以避免在发现问题后不得不重新进行收集。除了技术上如何生成它们的检查之外，您还可以收集更多的统计属性，以便更早地发现问题。这些属性可能包括变异性统计数据、完整分布、误差范围等（请参阅第2章“方法论”中的第2.8节“统计”）。在为代码更改或非回归测试进行基准测试时，了解变异性和误差范围至关重要，以便理解一对结果的意义。
还要尽可能多地从运行系统中收集性能数据（而不会因收集开销而影响结果），以便随后对这些数据进行法证分析。数据收集可能包括使用sar(1)、第三方产品和自定义工具来转储所有可用的统计数据。例如，在Linux上，一个自定义shell脚本可以在运行之前和之后复制/proc统计文件的内容。可以包括尽可能多的内容，以防需要。此类脚本还可以在基准测试期间定期执行，前提是性能开销可接受。还可以使用其他统计工具来创建日志。
在基于Solaris的系统上，可以使用kstat -p来转储所有内核统计数据，可以在运行之前和之后以及定期记录。这种输出易于解析，并且可以导入到数据库中进行高级分析。
对结果和指标的统计分析可以包括可扩展性分析和排队理论，以将系统建模为队列网络。这些主题在第2章“方法论”中进行了介绍，并且是独立文本的主题（[Jain 91]，[Gunther 97]，[Gunther 07]）。
12.4 Benchmark Questions
如果供应商提供了基准测试结果，你可以提出一些问题来更好地理解并将其应用到你的环境中。目标是确定实际测量了什么以及结果的真实性或可重复性如何。最困难的问题可能是：我能重现这个结果吗？基准测试结果可能来自极端的硬件配置（例如，DRAM磁盘）、特殊情况的调整（例如，条带磁盘）、偶然的运气（不可重复），或者是测量误差。如果你能在自己的数据中心运行并进行自己的分析，就可以确定其中的任何一个：主动基准测试。然而，这会消耗大量的时间。以下是可能提出的一些其他问题：
一般问题：
- 被测试系统的配置是什么？
- 是测试了单个系统，还是集群系统的结果？
- 被测试系统的成本是多少？
- 基准测试客户端的配置是什么？
- 测试的持续时间是多久？
- 结果是平均值还是峰值？平均值是多少？
- 其他分布细节是什么（标准偏差、百分位数或完整的分布细节）？
- 基准测试的限制因素是什么？
- 操作成功/失败的比率是多少？
- 操作属性是什么？
- 选择操作属性是为了模拟工作负载吗？它们是如何选择的？
- 基准测试模拟了方差还是平均工作负载？
- 基准测试结果是否使用其他分析工具进行了确认？（提供屏幕截图）
- 基准测试结果是否可以用误差范围来表达？
- 基准测试结果是否可重现？
对于与CPU/内存相关的基准测试：
- 使用了什么处理器？
- 是否禁用了任何CPU？
- 安装了多少主存？类型是什么？
- 是否使用了任何自定义BIOS设置？
对于与存储相关的基准测试：
- 存储设备的配置是什么（使用了多少个，类型是什么，RAID配置是什么）？
- 文件系统配置是什么（使用了多少个，调整是什么）？
- 工作集大小是多少？
- 工作集缓存到了什么程度？在哪里缓存了？
- 访问了多少个文件？
对于与网络相关的基准测试：
- 网络配置是什么（使用了多少个接口，类型和配置是什么）？
- 调整了哪些TCP设置？
研究行业基准测试时，许多这些问题可能可以从披露的细节中得到答案。