高性能MySQL:14---基准测试之基准测试工具与测试案例（BENCHMARK()函数、http_load、MySQL基准测试套件、sysbench、dbt2 TPC-C、TPCC-MySQL）

一、基准测试工具

集成式测试工具

• ab：
  • ab是一个Apache HTTP服务器基准测试工具。它可以测试 HTTP服务器每秒最多可以处理多少请求。如果测试的是Web应用 服务，这个结果可以转换成整个应用每秒可以满足多少请求。这是 个非常简单的工具，用途也有限，只能针对单个URL进行尽可能快 的压力测试。关于ab的更多信息可以参考http://httpd.apache.org/docs/2.0/programs/ab.html
• http_load：
  • 这个工具概念上和ab类似，也被设计为对Web服务器进行测 试，但比ab要更加灵活。可以通过一个输入文件提供多个 URL，http_load在这些URL中随机选择进行测试。也可以定 制http_load，使其按照时间比率进行测试，而不仅仅是测试最大请 求处理能力。更多信息请参考http://www.acme.com/software/http-%20load/
• JMeter：
  • JMeter是一个Java应用程序，可以加载其他应用并测试其性 能。它虽然是设计用来测试Web应用的，但也可以用于测试其他诸 如FTP服务器，或者通过JDBC进行数据库查询测试
  • JMeter比ab和http_load都要复杂得多。例如，它可以通过控制 预热时间等参数，更加灵活地模拟真实用户的访问。JMeter拥有绘 图接口（带有内置的图形化处理的功能），还可以对测试进行记 录，然后离线重演测试结果。更多信息请参考http://jakarta.apache.org/jmeter/

单组件式测试工具

• mysqlslap：
  • mysqlslap（http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html 可以模拟服务器的负载，并输出计时信息。它包含在MySQL 5.1的 发行包中，应该在MySQL 4.1或者更新的版本中都可以使用。测试 时可以执行并发连接数，并指定SQL语句（可以在命令行上执行， 也可以把SQL语句写入到参数文件中）。如果没有指定SQL语 句，mysqlslap会自动生成查询schema的SELECT语句
• MySQL Benchmark Suite（sql-bench）：
  • 在MySQL的发行包中也提供了一款自己的基准测试套件，可 以用于在不同数据库服务器上进行比较测试。它是单线程的，主要 用于测试服务器执行查询的速度。结果会显示哪种类型的操作在服 务器上执行得更快
  • 这个测试套件的主要好处是包含了大量预定义的测试，容易使 用，所以可以很轻松地用于比较不同存储引擎或者不同配置的性能 测试。其也可以用于高层次测试，比较两个服务器的总体性能。当 然也可以只执行预定义测试的子集（例如只测试UPDATE的性能）。 这些测试大部分是CPU密集型的，但也有些短时间的测试需要大量 的磁盘I/O操作
  • 这个套件的最大缺点主要有：它是单用户模式的，测试的数据 集很小且用户无法使用指定的数据，并且同一个测试多次运行的结 果可能会相差很大。因为是单线程且串行执行的，所以无法测试多 CPU的能力，只能用于比较单CPU服务器的性能差别。使用这个套 件测试数据库服务器还需要Perl和BDB的支持，相关文档请参 考http://dev.mysql.com/doc/en/mysql-benchmarks.html/
• Super Smack：
  • Super Smack（http://vegan.net/tony/supersmack/）是一款用于 MySQL和PostgreSQL的基准测试工具，可以提供压力测试和负载生 成。这是一个复杂而强大的工具，可以模拟多用户访问，可以加载 测试数据到数据库，并支持使用随机数据填充测试表。测试定义 在“smack”文件中，smack文件使用一种简单的语法定义测试的客户 端、表、查询等测试要素
• Database Test Suite：
  • Database Test Suite是由开源软件开发实验室（OSDL，Open Source Development Labs）设计的，发布在SourceForge网站 （http://sourceforge.net/projects/osdldbt/）上，这是一款类似某些工 业标准测试的测试工具集，例如由事务处理性能委员会（TPC， Transaction Processing Performance Council）制定的各种标准。特别 值得一提的是，其中的dbt2就是一款免费的TPC-C OLTP测试工具 （未认证）。之前本书作者经常使用该工具，不过现在已经使用自 己研发的专用于MySQL的测试工具替代了
• Percona's TPCC-MySQL Tool：
  • 我们开发了一个类似TPC-C的基准测试工具集，其中有部分是 专门为MySQL测试开发的。在评估大压力下MySQL的一些行为 时，我们经常会利用这个工具进行测试（简单的测试，一般会采 用sysbench替代）。该工具的源代码可以 在下载，在源码库中有一个简单的文档说明https://launchpad.net/perconatools
• sysbench：
  • sysbench（https://launchpad.net/sysbench）是一款多线程系统压 测工具。它可以根据影响数据库服务器性能的各种因素来评估系统 的性能。例如，可以用来测试文件I/O、操作系统调度器、内存分 配和传输速度、POSIX线程，以及数据库服务器等。sysbench支持 Lua脚本语言（http://www.lua.org），Lua对于各种测试场景的设置 可以非常灵活。sysbench是我们非常喜欢的一种全能测试工具，支 持MySQL、操作系统和硬件的硬件测试

二、BENCHMARK()函数

三、测试案例（http_load）

• 下面通过一个简单的例子来演示如何使用http_load。首先创建一 个urls.txt文件，输入如下的URL：

• http_load最简单的用法，就是循环请求给定的URL列表。测试程序 将以最快的速度请求这些URL：

• 测试的结果很容易理解，只是简单地输出了请求的统计信息。下面 是另外一个稍微复杂的测试，还是尽可能快地循环请求给定的URL列 表，不过模拟同时有五个并发用户在进行请求：

• 另外，除了测试最快的速度，也可以根据预估的访问请求率（比如 每秒5次）来做压力模拟测试。

• 最后，还可以模拟更大的负载，可以将访问请求率提高到每秒20次 请求。请注意，连接和请求响应时间都会随着负载的提高而增加。

四、测试案例（MySQL基准测试套件）

• MySQL基准测试套件（MySQL Benchmark Suite）由一组基于Perl 开发的基准测试工具组成。在MySQL安装目录下的sql-bench子目录中包 含了该工具。比如在Debian GNU/Linux系统上，默认的路径 是/usr/share/mysql/sql-bench
• 在用这个工具集测试前，应该读一下README文件，了解使用方法 和命令行参数说明。如果要运行全部测试，可以使用如下的命令：

• 运行全部测试需要比较长的时间，有可能会超过一个小时，其具体 长短依赖于测试的硬件环境和配置。如果指定了--log命令行，则可以监 控到测试的进度。测试的结果都保存在output子目录中，每项测试的结 果文件中都会包含一系列的操作计时信息。下面是一个具体的例子，为 方便印刷，部分格式做了修改

• 如上所示，count_distinct_group_on_key（1000:6000）测试花费 了34秒（wallclock secs），这是客户端运行测试花费的总时间；其他值 （包括usr，sys，cursr，csys）则占了测试的0.28秒的开销，这是运 行客户端测试代码所花费的时间，而不是等待MySQL服务器响应的时 间。而测试者真正需要关心的测试结果，是除去客户端控制的部分，即 实际运行时间应该是33.72秒
• 除了运行全部测试集外，也可以选择单独执行其中的部分测试项。 例如可以选择只执行 insert测试，这会比运行全部测试集所得到的汇总信息给出更多的 详细信息：

五、测试案例（sysbench）

• sysbench可以执行多种类型的基准测试，它不仅设计用来测试数据 库的性能，也可以测试运行数据库的服务器的性能。实际上，Peter和 Vadim最初设计这个工具是用来执行MySQL性能测试的（尽管并不能完 成所有的MySQL基准测试）。下面先演示一些非MySQL的测试场景， 来测试各个子系统的性能，这些测试可以用来评估系统的整体性能瓶 颈。后面再演示如何测试数据库的性能
• 强烈建议大家都能熟悉sysbench测试，在MySQL用户的工具包中， 这应该是最有用的工具之一。尽管有其他很多测试工具可以替代 sysbench的某些功能，但那些工具有时候并不可靠，获得的结果也不一 定和MySQL性能相关。例如，I/O性能测试可以用iozone、bonnie++等 一系列工具，但需要注意设计场景，以便可以模拟InnoDB的磁盘I/O模 式。而sysbench的I/O测试则和InnoDB的I/O模式非常类似，所以fleio选 项是非常好用的

sysbench的CPU基准测试

• 最典型的子系统测试就是CPU基准测试。该测试使用64位整数，测 试计算素数直到某个最大值所需要的时间。下面的例子将比较两台不同 的GNU/Linux服务器上的测试结果。第一台机器的CPU配置如下：

• 在这台服务器上运行如下的测试：

• 第二台服务器配置了不同的CPU：

• 测试的结果简单打印出了计算出素数的时间，很容易进行比较。在 上面的测试中，第二台服务器的测试结果显示比第一台快两倍

sysbench的文件I/O基准测试

• 文件I/O（fileio）基准测试可以测试系统在不同I/O负载下的性 能。这对于比较不同的硬盘驱动器、不同的RAID卡、不同的RAID模 式，都很有帮助。可以根据测试结果来调整I/O子系统。文件I/O基准测 试模拟了很多InnoDB的I/O特性
• 测试的第一步是准备（prepare）阶段，生成测试用到的数据文件， 生成的数据文件至少要比内存大。如果文件中的数据能完全放入内存 中，则操作系统缓存大部分的数据，导致测试结果无法体现I/O密集型 的工作负载。首先通过下面的命令创建一个数据集：

• 这个命令会在当前工作目录下创建测试文件，后续的运行（run） 阶段将通过读写这些文件进行测试。第二步就是运行（run）阶段，针 对不同的I/O类型有不同的测试选项：
  • seqwr：顺序写入
  • seqrewr：顺序重写
  • seqrd：顺序读取
  • rndrd：随机读取
  • rndwr：随机写入
  • rdnr：混合随机读/写
• 下面的命令运行文件I/O混合随机读/写基准测试：

• 输出结果中包含了大量的信息。和I/O子系统密切相关的包括每秒 请求数和总吞吐量。在上述例子中，每秒请求数是223.67 Requests/sec， 吞吐量是3.4948MB/sec。另外，时间信息也非常有用，尤其是大约95％ 的时间分布。这些数据对于评估磁盘性能十分有用
• 测试完成后，运行清除（cleanup）操作删除第一步生成的测试文 件：

sysbench的OLTP基准测试

• OLTP基准测试模拟了一个简单的事务处理系统的工作负载。下面 的例子使用的是一张超过百万行记录的表，第一步是先生成这张表：

• 生成测试数据只需要上面这条简单的命令即可。接下来可以运行测 试，这个例子采用了8个并发线程，只读模式，测试时长60秒：

• 如上所示，结果中包含了相当多的信息。其中最有价值的信息如 下：
  • 总的事务数
  • 每秒事务数
  • 时间统计信息（最小、平均、最大响应时间，以及95％百分比响应 时间）
  • 线程公平性统计信息（thread-fairness），用于表示模拟负载的公平 性
• 这个例子使用的是sysbench的第4版，在SourceForge.net可以下载到 这个版本的编译好的可执行文件。也可以从Launchpad下载最新的第5版 的源代码自行编译（这是一件简单、有用的事情），这样就可以利用很 多新版本的特性，包括可以基于多个表而不是单个表进行测试，可以每 隔一定的间隔比如10秒打印出吞吐量和响应的结果。这些指标对于理解 系统的行为非常重要

sysbench的其它特性

• sysbench还有一些其他的基准测试，但和数据库性能没有直接关系
  • memory内存（memory） 测试内存的连续读写性能
  • 线程（thread） 测试线程调度器的性能。对于高负载情况下测试线程调度器的 行为非常有用
  • 互斥锁（mutex） 测试互斥锁（mutex）的性能，方式是模拟所有线程在同一时 刻并发运行，并都短暂请求互斥锁（互斥锁mutex是一种数据结 构，用来对某些资源进行排他性访问控制，防止因并发访问导致问 题）
  • 顺序写（seqwr） 测试顺序写的性能。这对于测试系统的实际性能瓶颈很重要。 可以用来测试RAID控制器的高速缓存的性能状况，如果测试结果 异常则需要引起重视。例如，如果RAID控制器写缓存没有电池保 护，而磁盘的压力达到了3000次请求/秒，就是一个问题，数据可 能是不安全的。
• 另外，除了指定测试模式参数（--test）外，sysbench还有其他很多 参数，比如--num-threads、--max-requests和--max-time参数，更多信息请 查阅相关文档

六、测试案例（数据库测试套件中的dbt2 TPC-C测试）

• 数据库测试套件（Database Test Suite）中的dbt2是一款免费的TPCC测试工具。TPC-C是TPC组织发布的一个测试规范，用于模拟测试复 杂的在线事务处理系统（OLTP）。它的测试结果包括每分钟事务数 （tpmC），以及每事务的成本（Price/tpmC）。这种测试的结果非常依 赖硬件环境，所以公开发布的TPC-C测试结果都会包含具体的系统硬件 配置信息
• dbt2并不是真正的TPC-C测试，它没有得到TPC组织的认证，它的结果不能直接跟 TPC-C的结果做对比

下面看一个设置和运行dbt2基准测试的例子。这里使用的是dbt2 0.37版本，这个版本能够支持MySQL的最新版本（还有更新的版本，但 包含了一些MySQL不能提供完全支持的修正）。下面是测试步骤。

• 1.准备测试数据
  • 下面的命令会在指定的目录创建用于10个仓库的数据。每个仓 库使用大约700MB磁盘空间，测试所需要的总的磁盘空间和仓 库的数量成正比。因此，可以通过-w参数来调整仓库的个数以 生成合适大小的数据集

• 2.加载数据到MySQL数据库
  • 下面的命令创建一个名为dbt2w10的数据库，并且将上一步生成 的测试数据加载到数据库中（-d参数指定数据库，-f参数指定测 试数据所在的目录）。

• 3.运行测试
  • 最后一步是运行scripts脚本目录中的如下命令执行测试：

• 最重要的结果是输出信息中末尾处的一行：

• 这里显示了系统每分钟可以处理的最大事务数，越大越好（neworder并非一种事务类型的专用术语，它只是表明测试是模拟用户在假想 的电子商务网站下的新订单）
• 通过修改某些参数可以定制不同的基准测试
  • -c 到数据库的连接数。修改该参数可以模拟不同程度的并发性， 以测试系统的可扩展性
  • -e 启用零延迟（zero-delay）模式，这意味着在不同查询之间没 有时间延迟。这可以对数据库施加更大的压力，但不符合真实情 况。因为真实的用户在执行一个新查询前总需要一个“思考时间 （think time）”
  • -t 基准测试的持续时间。这个参数应该精心设置，否则可能导致 测试的结果是无意义的。对于I/O密集型的基准测试，太短的持续 时间会导致错误的结果，因为系统可能还没有足够的时间对缓存进 行预热。而对于CPU密集型的基准测试，这个时间又不应该设置得 太长；否则生成的数据量过大，可能转变成I/O密集型
• 这种基准测试的结果，可以比单纯的性能测试提供更多的信息。例 如，如果发现测试有很多的回滚现象，那么就可以判定很可能什么地方 出现错误了

七、测试案例（Percona的TPCC-MySQL测试工具）

• 尽管sysbench的测试很简单，并且结果也具有可比性，但毕竟无法 模拟真实的业务压力。相比而言，TPC-C测试则能模拟真实压力。2.5.4 节谈到的dbt2是TPC-C的一个很好的实现，但也还有一些不足之处。为 了满足很多大型基准测试的需求，本书的作者重新开发了一款新的类 TPC-C测试工具，代码放在Launchpad上，可以通过如下地址获 取：https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql，其 中包含了一个README文件说明了如何编译。该工具使用很简单，但 测试数据中的仓库数量很多，可能需要用到其中的并行数据加载工具来 加快准备测试数据集的速度，否则这一步会花费很长时间
• 使用这个测试工具，需要创建数据库和表结构、加载数据、执行测 试三个步骤。数据库和表结构通过包含在源码中的SQL脚本创建。加载 数据通过用C写的tpcc_load工具完成，该工具需要自行编译。加载数据 需要执行一段时间，并且会产生大量的输出信息（一般都应该将程序输 出重定向到文件中，这里尤其应该如此，否则可能丢失滚动的历史信 息）

演示案例

• 下面的例子显示了配置过程，创建了一个小型（五个仓库）的测 试数据集，数据库名为tpcc5

• 然后，使用tpcc_start工具开始执行基准测试。其同样会产生很多输 出信息，还是建议重定向到文件中。下面是一个简单的示例，使用五个 线程操作五个仓库，30秒预热时间，30秒测试时间：

• 最后一行就是测试的结果：每分钟执行完的事务数(11)。如果紧挨 着最后一行前发现有异常结果输出，比如有关于约束检查的信息，那么 可以检查一下响应时间的直方图，或者通过其他详细输出信息寻找线 索。当然，最好是能使用本章前面提到的一些脚本，这样就可以很容易 获得测试执行期间的详细的诊断数据和性能数据