MySQL 基准测试



前言：第二章基准测试的内容有理论也有实践，这里村民并没有时间和精力为大家展现一些实践数据，仅摘录理论部分。如果大家对实践有兴趣，可以自行学习，肯定也是不错的经验。



基准测试 ( benchmark ) 是针对系统设计的一种压力测试，通常的目标是为了掌握系统的行为，但也有其他原因，如重现某个系统状态，或者是做新硬件的可靠性测试。本章将讨论 MySQL 和基于 MySQL 的应用的基准测试的重要性、策略和工具。



2.1 为什么需要基准测试



基准测试是唯一方便有效的、可以学习系统在给定的工作负载下会发生什么的方法。基准测试可以观察系统在不同压力下的行为，评估系统的容量，掌握哪些是重要的变化，或者观察系统如何处理不同的数据。基准测试可以在系统实际负载之外创造一些虚构场景进行测试。基准测试可以完成以下工作，或者更多：



• 验证基于系统的一些假设，确认这些假设是否符合实际情况。

• 重现系统中的某些异常行为，以解决这些异常。

• 测试系统当前的运行情况。

• 模拟比当前系统更高的负责的负载，以找出系统随着压力增加而可能遇到的扩展性瓶颈。

• 规划未来的业务增长。

• 测试应用适应可变环境的能力。

• 测试不同的硬件、软件和操作系统配置。

• 证明新采购的设备是否配置正确。



基准测试还可以用于其他目的，比如为应用创建单元测试套件。



基准测试的一个主要问题在于其不是真实压力的测试。基准测试施加给系统的压力相对真实压力来说，通常比较简单。真实压力是不可预期而且变化多端的，有时候情况会过于复杂而难以解释，所以使用真实压力测试，可能难以从结果中分析出确切的结论。



基准测试的压力和真实压力有哪些方面不同？有很多因素会影响基准测试，比如数据量、数据和查询的分布，但最重要的一点还是基准测试通常要求尽可能快地执行完成，所以经常给系统造成过大的压力。在很多案例中，我们都会调整给测试工具的最大压力，以在系统可以容忍的压力阈值内尽可能快地执行测试，这对于系统的最大容量非常有帮助，然而大部分压力测试工具不支持对压力进行复杂的控制。务必记住，测试工具自身的局限也会影响结果的有效性。



在使用基准测试进行容量规划时也要掌握技巧，不能只根据测试结果做简单的推断。基本上，我们只能进行大概的测试来确定系统大致的余量有多少。当然也可以做一些真实压力测试（和基准测试有区别），但在构造数据集和压力的时候要特别小心，而且这样就不再是基准测试了。基准测试要尽量简单直接，结果之间容易相互比较，成本低且易于执行。尽管有很多限制，基准测试还是非常有用的。



2.2 基准测试的策略



基准测试有两种主要的策略：一是针对整个系统的整体测试，另外是单独测试 MySQL。这两种策略也被称为集成式 ( full-stack ) 以及单组件式 ( single-component ) 基准测试。针对整个系统做集成式测试，而不是单独测试 MySQL 的原因最主要有以下几点：



• 测试整个应用系统，包括 Web 服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是 MySQL 本身的性能，而是应用整体的性能。

• MySQL 并非总是应用的瓶颈，通过整体测试可以揭示这一点。

• 只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。

• 整体应用的集成式测试更能揭示应用的真实表现，而单独组建的测试很难做到这一点。



另外一方面，应用的整体基准测试很难建立，甚至很难正确设置。如果基准测试的设计有问题，那么结果就无法反映真实的情况，从而基于此做的决策也就可能是错误的。



不过有时候不需要了解整个应用的情况，而只需要关注 MySQL 的性能，至少在项目初期可以这样做。基于以下情况，可以选择只测试 MySQL：



• 需要比较不同的 schema 或查询的性能。

• 针对应用中某个具体问题的测试。

• 为了避免蛮长的基准测试，可以通过一个短期的基准测试，做快速的 ” 周期循环 “ 来检测出某些调整后的效果。



另外，如果能够在真实的数据集上执行重复的查询，那么针对 MySQL 的基准测试也是有用的，但是数据本身和数据集的大小都应该是真实的。如果可能，可以采用生产环境的数据快照。



不幸的是，设置一个基于真实数据的基准测试复杂而且耗时。如果能得到一份生产数据集的拷贝，当然很幸运，但这通常不可能。比如要测试的是一个刚开发的新应用，它只有很少的用户和数据，如果像测试该应用在规模扩张到很大以后的性能表现，就只能通过模拟大量的数据压力来进行。



2.2.1 测试何种指标



在开始执行甚至是在设计基准测试之前，需要先明确测试的目标。测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。有时候需要用不同的方法测试不同的指标。比如，针对延迟 ( latency ) 和吞吐量 ( throughput ) 就需要采用不同的测试方法。请考虑以下指标，看看如何满足测试的需求。



• 吞吐量：吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。一些标准的基准测试被广泛地引用，如 TPC-C，而且很多数据库厂商都努力争取在这些测试中取得好成绩。这类基准测试主要针对在线事务处理 ( OLTP ) 的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数 ( TPS )，有些也采用每分钟事务数 ( TPM )。

• 响应时间或者延迟：这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间通常意义不大，因为测试时间越长，最大响应时间也可能越大，而且其结果通常不可重复，每次测试都可能得到不同的最大响应时间。因此，通常可以使用百分比响应时间 ( percentile response time ) 来替代最大响应时间。例如，如果 95% 的响应时间都是 5 毫秒，则表示任务在 95% 的时间段内都可以在 5 毫秒内完成。使用图标有助于理解测试结果，可以将测试结果绘制成折线图或者散点图，直观地表现数据结果集的分布情况，也可以通过这些图发现长时间测试的趋势。

• 并发性：并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或者连接数。当并发性增加时，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。并发性的测量完全不同于响应时间和吞吐量，它不像是一个结果，而更像是设置基准测试的一种属性。并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。当然，数据库的并发性还是需要测量的，可以通过 sysbench 指定 32、64 或者 128 个线程的测试，然后在测试期间记录 MySQL 数据库的 Threads_running 状态值。

• 可扩展性：在系统的业务压力可能发生变化的情况下，测试可扩展性就非常必要了。简单来说，可扩展性指的是给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍），或者说给系统增加一倍的资源（比如两倍的 CPU 数），就可以获得两倍的吞吐量。当然，同时性能（响应时间）也必须在可以接受的范围内。大多数系统是无法做到如此理想的线性扩展的。随着压力的变化，吞吐量和性能都可能越来越差。可扩展性指标对于容量规范非常有用，它可以提供其他测试无法提供的信息来帮助发现应用的瓶颈。



归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，比如什么样的响应时间是可以接受的、期待多少的并发性等等，然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标而忽略其他指标。



2.3 基准测试方法



在了解基本概念之后，现在可以来具体讨论一下如何设计和执行基准测试。但在讨论如何设计好的基准测试之前，先来看一下如何避免一些常见的错误，这些错误可能导致测试结果无用或者不精确：



• 使用真实数据的子集而不是全集。例如应用需要处理几百 GB 的数据，但测试只有 1GB 数据，或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。

• 使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）。

• 使用不真实的分布参数。例如假定所有用户的个人信息都会被平均地读取。

• 在多用户场景中，只做单用户的测试。

• 在单服务器上测试分布式应用。

• 与真实用户行为不匹配。

• 反复执行同一查询。真实的查询是不尽相同的，这可能会导致缓存命中率降低，而反复执行同一查询在某种程度上会全部或者部分缓存结果。

• 没有检查错误。如果测试的结果无法得到合理的解释，比如一个本应该很慢的查询突然变快了，就应该检查是否有错误产生，否则可能只是测试了 MySQL 检测语法错误的速度了。基准测试完成后，一定要检查一下错误日志，这应当是基本的要求。

• 忽略了系统预热 ( warm up ) 的过程。例如系统重启后马上进行测试，有时候需要了解系统重启后需要多长时间才能达到正常的性能容量，要特别留意预热的时长。反过来说，如果想要分析正常的性能，需要注意的是，若基准测试在重启以后马上启动，则缓存是冷、还没有数据，这时即使测试的压力相同，得到的结果也和缓存已经装满数据时是不同的。

• 使用默认的服务器配置。

• 测试时间太短。基准测试需要持续一定的时间。



如果其他条件相同，就应努力使测试过程尽可能地接近真实应用的情况。当然，有时候和真实情况稍有些初入问题也不大。例如实际应用服务器和数据库服务器分别部署在不同的机器。如果采用和实际部署完全相同的配置当然更真实，但也会引入更多的变化因素，比如加入了网络的负载和速度等，而在单一节点上运行测试相对要容易，在某些情况下结果也可以接受，那么就可以在单一节点上进行测试。当然，这样的选择需要根据实际情况来分析是否合适。



2.3.1 设计和规划基准测试



规划基准测试的第一步是提出问题并明确目标，然后决定是采用标准的基准测试，还是设计专用的测试。



如果采用标准的基准测试，应该确认选择了合适的测试方案。例如，不要使用 TPC-H 测试电子商务系统。在 TPC 的定义中，“ TPC-H 是即席查询和决策支持型应用的基准测试”，因此不适合用来测试 OLTP 系统。



设计专用的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照，并且该快照很容易还原，以便进行后续的测试。然后针对数据运行查询。可以建立一个单元测试集作为初步的测试，并运行多遍，但是这和真是的数据库环境还是有差别的，更好的办法是选择一个有代表性的时间段，比如高峰期的一个小时或者一整天，记录生产系统上的所有查询。如果时间段选得比较小，则可以选择多个时间段。这样有助于覆盖整个系统的活动状态，例如每周报表的查询或者非峰值时间运行的批处理作业。



可以在不同级别记录查询。例如，如果是集成式 ( full-stack ) 基准测试，可以记录 Web 服务器上的 HTTP 请求，也可以打开 MySQL 的查询日志 ( Query Log )。倘若要重演这些查询，就要确保创建多线程并行执行，而不是单个线程线性地执行。对日志中的每个连接都应该创建独立的线程，而不是将所有的查询随机地分配到一些线程中。查询日志中记录了每个查询是在哪个连接中执行的。



即使不需要创建专用的基准测试，详细地写下测试规划也是必需的。测试可能要多次反复运行，因此需要精确地重现测试过程，而且也应该考虑到未来，执行下一轮测试时可能已经不是同一个人了。即使还是同一个人，也有可能不会确切地记得初次运行时的情况。测试规划应该记录测试数据、系统配置的步骤、如何测量和分析结果，以及预热的方案等。应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。文档规范可以很简单，比如采用电子表格或者记事本形式，也可以是复杂的自定义的数据库。需要记住的是，经常要写一写脚本来分析测试结果，因此如果能够不用打开电子表格或者文本文件等额外操作，当然是更好的。



2.3.2 基准测试应该运行多长时间



基准测试应该运行足够长的时间，如果需要测试系统在稳定状态时的性能，那么当然需要在稳定状态下测试并观察，而如果系统有大量的数据和内存，要达到稳定状态可能需要非常长的时间。大部分系统都会有一些应对突发情况的余量，能够吸收性能尖峰，将一些工作延迟到高峰期之后执行，但当对机器加压足够长时间之后，这些余量会被消耗尽，系统的短期尖峰也就无法维持原来的高性能。有时候无法确认测试需要运行多长的时间才足够，如果是这样，可以让测试一直运行，持续观察指导确认系统已经稳定。



2.3.3 获取系统性能和状态



在执行基准测试时，需要尽可能多地手机被测试系统的信息。最好为基准测试建立一个目录，并且每执行一轮测试都创建单独的子目录，将测试结果、配置文件、测试指标、脚本和其他相关说明都保存在其中。即使有些结果不是目前需要的，也应该先保存下来。多余一些数据总比缺乏重要的数据要好，而且多余的数据以后也许会用得着。需要记录的数据包括系统状态和性能指标，诸如 CPU 使用率、磁盘 I/O、网络流量统计、SHOW GLOBAL STATUS 计数器等。



2.3.4 获得准确的测试结果



获得准确测试结果的最好办法是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？



接着确认测试结果是否可重复。每次重新测试之前要确保系统的状态是一致的。如果是非常重要的测试，甚至有必要每次测试都重启系统。一般情况下，需要测试的是经过预热的系统，还需要确保预热的时间足够长、是否可重复。如果预热采用的是随机查询，那么测试结果可能就是不可重复的。



如果测试的过程会修改数据或者 schema，那么每次测试钱，需要利用快照还原数据。在表中插入 1000 条记录和 插入 100 万条记录，测试结果肯定不会相同。数据的碎片度和在磁盘上的分布，都可能导致测试是不可重复的。一个确保物理磁盘数据的分布尽可能一致的办法是，每次都进行快速格式化并进行磁盘分区复制。



很多因素，包括外部的压力、性能分析和监控系统、详细的日志记录、周期性作业以及其他一些因素，都会影响到测试结果。在每次测试中，修改的参数应该尽量少。如果必须要一次修改多个参数，那么可能会丢失一些信息。有些参数依赖其他参数，这些参数可能无法单独修改。有时候甚至都没意识到这些依赖，这给测试带来了复杂性。一般情况下都是通过迭代逐步地修改基准测试的参数，而不是每次运行时都做大量的修改。举个例子，如果要通过调整参数来创造一个特定行为，可以通过使用分治法 ( divide-and-conquer, 每次运行时将参数对分减半 ) 来找到正确的值。



另外，基于 MySQL 的默认配置的测试没有什么意义，因为默认配置是基于消耗很少内存的极小应用的。最后，如果测试中出现异常结果，不要轻易当做坏数据点而丢弃。应该认真研究并找到产生这种结果的原因。测试可能会得到有价值的结果，或者一个严重的错误，抑或基准测试的设计缺陷。



2.3.5 运行基准测试并分析结果



一旦准备就绪，就可以着手基准测试，收集和分析数据了。通常来说，自动化基准测试是个好主意。这样做可以获得更精确的测试结果，因为自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。另外也有助于归档整个测试过程。



自动化的方式有很多，可以是一个 Makefile 文件或者一组脚本。脚本语言可以根据需要选择：shell、PHP、Perl 等都可以，要尽可能地使所有测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。



一旦设置了正确的自动化操作，基准测试将成为一步式操作。如果只是针对某些应用做一次性的快速验证测试，可能就没必要做自动化。但只要未来可能会引用到测试结果，建议都尽量地自动化。否则到时候可能就搞不清楚是如何获得这个结果的，也不记得采用了什么参数，这样就很难再通过测试重现结果了。



基准测试通常需要运行多次。具体需要运行多少次要看对结果的记分方式，以及测试的重要程度。要提高测试的准确度，就需要多运行几次。一般在测试的实践中，可以取最好的结果值，或者所有结果的平均值，抑或从五个测试结果里取最好三个值的平均值。可以根据需要更进一步精确化测试结果，还可以对结果使用统计方法，确定置信区间等。不过通常来说，只要测试的结果能满足目前的需求，简单地运行几轮测试，看看结果的变化就可以了。如果结果变化很大，可以再多运行几次，或者运行更长的时间，这样都可以获得更准确的结果。



获得测试结果后，还需要对结果进行分析，也就是说，要把 “ 数字 ” 变成 “ 知识 ”。最终的目的是回答在设计测试时的问题。如何从数据中抽象出有意义的结果，依赖于如何收集数据。通常需要写一写脚本来分析数据，这不仅能减轻分析的工作量，而且和自动化基准测试一样可以重复运行，并易于文档化。