MySQL之基准测试

电玩女神 2022-05-09 04:28 271阅读 0赞

> 基准测试（benchmark）是针对系统设计的一种压力测试。通常的目标是为了掌握系统的行为。但也有其他原因，如重新某个系统状态，或者做新硬件的可靠性测试。

### 文章目录 ###

*  为什么需要基准测试
 *  基准测试的策略
 *   *  测试何种指标
 *  基准测试的方法
 *   *  设计和规划基准测试
     *  基准测试应该运行多长时间
     *  获取系统性能和状态
     *  获得准确的测试结果
     *  运行基准测试并分析结果
 *  基准测试工具
 *   *  集成式测试工具
     *  单组件式测试工具
     *  MySQL的BENCHMARK()函数

# 为什么需要基准测试 #

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

1.  验证基于系统的一些假设，确认这些假设是否符合实际情况。
2.  重新系统中的某些异常行为，以解决这些异常。
3.  测试系统当前的运行情况。如果不清楚系统当前的性能，就无法确认某些优化的效果如何。
4.  模拟比系统更高的负载，以找出随着压力增加而可能遇到的扩展性瓶颈。
5.  规划未来的业务增长。基准测试可以评估项目在未来的负载下，需要什么样的硬件，需要多大容量的网络，以及其他相关资源。这有助于降低系统升级和重大变更的风险。
6.  测试应用适应可变环境的能力。如，通过基准测试，可以发现系统在随机的并发峰值下的性能表现，或者不同服务器直接的性能表现。基准测试可以测试系统对不同数据分布的处理能力。
7.  测试不同的硬件、软件和操作系统配置。
8.  证明新采购的设备是否配置正确。
9.  为应用创建单元参数套件。

*  基准测试的一个主要问题在于不是真实压力的测试。基准测试施加给系统的压力相对于真实压力来说，通常比较简单。真实压力是不可预期而且变化多端的，有时候情况过于复杂而难以解释。所以使用真实压力测试，可能很难从结果中分析出正确的结论。
 *  基准测试的压力和真实压力有那些方面不同？有很多因素会影响基准测试，如数据量、数据和查询的分布，但最重要的哈市基准测试通常要求尽可能快地执行完成，所以通常给系统造成过大的压力。在很多案例中，我们都会调整给测试工具的最大压力，以在系统可以容忍的压力阈值内尽可能快地执行测试，这对于确定系统的最大容量非常有帮助。而大部分压力测试工具不支持对压力进行复杂的控制。务必要记住，测试工具自身的局限也会影响到结果的有效性。
 *  使用基准测试进行容量规划也要掌握技巧，不能只根据测试结果做简单的推断。
 *  结论就是，我们只能进行大概的测试，来确定系统大致的余量是多少。当然也可以做一些真实压力测试（和基准测试有区别），但在构造数据集和压力的时候要特别小心，而且这样就不再是基准测试了。基准测试要尽量简单直接，结果之间容易相互比较，成本低且易于执行。

# 基准测试的策略 #

基准测试有两种主要的策略：一是针对整个系统的整体测试（集成式基准测试 full-stack），另外是单独测试MySQL（single-componet）。针对整个系统做集成式测试，而不是单独测试MySQL的原因如下：

1.  测试整个应用系统，包括Web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是MySQL本身的性能，而是应用整体的性能。
2.  MySQL并非总数应用的瓶颈，通过整体的测试可以揭示这一点。
3.  只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。
4.  整体应用的集成式测试更能揭示应用的真实表现，而单独组件的测试很那做到这引导。

*  另外一方面，应用的整体基准测试很难建立，甚至很难正确设置。如果基准测试的设计有问题，那么结果就无法反映真实的情况，从而基于此做的决策也就可能是错误的。
 *  有时候并不需要了解整体应用的情况，只需要关注MySQL的性能，至少项目初期可以这样做。以下情况，可以只测试MySQL:

1.  需要比较不同的schema或查询的性能。
2.  针对应用中某个具体问题的测试。
3.  为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果。

如果可能，可以采用生产环境的数据快照。

## 测试何种指标 ##

在开始执行甚至是在设计基准测试之前，需要先明确测试的目标。测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。可以将测试目标细化为一系列的问题，如，“这种CPU是否比另一种更快”，或"新索引是否比当前索引性能更好？"

有时候需要用不同的方法测试不同的指标。比如，针对延迟（latency）和吞吐量（throughput）就需要采用不同的测试方法。

**请考虑以下指标，看看如何满足测试的需求。**

*  吞吐量  
    吞吐量指的是单位时间内的事务处理数 。这一直是经典的数据库应用测试指标。这类基准测试主要针对在线事务处理（OLTP）的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数（TPS），或每分钟事务数（TPM）。
 *  响应时间或者延迟  
    这个指标用于测试任务所需的整体时间。测试的时间单位可能是微妙、毫秒、秒或者分钟。根据时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占的百分比。通常可以使用百分比响应时间（percentile response time）来代替最大响应时间。例如，如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒内完成。  
    使用图表有助于理解测试结果。可以将测试结果绘制成折线图（比如平均值折线或者95％百分比折线）或者散点图，直观地表现数据结果集的分布情况。通过这些图可以发现长时间测试的趋势。
 *  并发性  
    并发性是一个飞铲重要又被经常误解和误用的指标。  
    Web服务器的高并发，一般会导致数据库的高并发，但服务器采用的语言和工具集对此都会产生影响。注意不要将数据库连接和并发性搞混淆。一个设计良好的应用，同时可以打开成百上千个MySQL数据库服务器连接，但可能同时只有少数连接正在执行查询。所有说，一个Web站点"同时有50000个用户"访问，却可能只有10~15个并发请求到MySQL数据库。  
    换句话说，并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数和连接上。当并发性增加时，需要测试吞吐量是否下降，响应时间是否变长，如果是这样，应用可能无法处理峰值压力。  
    并发性的测试完全不同于响应时间和吞吐量，它不想是一个结果，更新是设置基准测试的一种属性。并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。当然，数据库的并发性还是需要测量的。可以通过sysbench 指定32、64或者128个线程的测试，然后在测试期间记录MySQL数据库的Threads\_running 状态值。
 *  可扩展性  
    在系统的业务压力可能发生变化的情况下，测试可扩展性就非常必要了。简单的说，可扩展性指的是，给系统增加一倍的工作，在理想的情况下就能获得两倍的结果（即吞吐量增加一倍）。或者说，给系统增加一倍的资源（比如两倍的CPU数），就可以获得两倍的吞吐量。当然，同时性能（响应时间）也必须在可以接受的范围内。大多数系统是无法做到如此理想的线性扩展的。随着压力的变化，吞吐量和性能都可能越来越差。

一些任务，比如从细粒度数据创建汇总表的批量工作，需要的是周期性的快速响应时间。当然也可以测试这些任务纯粹的响应时间，但要注意考虑这些任务之间的相互影响。批量工作可能导致相互之间有影响的查询性能变差，反之亦然。

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

# 基准测试的方法 #

以下错误可能导致测试结果无用或者不精确：

1.  使用真实数据的子集而不是全集。例如应用需要处理几百GB的数据，但测试只有1GB数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。
2.  使用错误的数据分布。 例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域。
3.  使用不真实的分布参数。
4.  在多用户场景中，制作单用户的测试。
5.  在单服务器上测试分布式应用。
6.  与真实用户行为不匹配。例如Web页面中的“思考时间”。真实用户在请求到一个页面后会阅读一段时间，而不是不停顿地一个接一个点击相关链接。
7.  反复执行同一查询。
8.  没有检查错误。如果测试的结果无法得到合理的解释，比如一个本应该很慢的查询突然变快了，就应该检查是否有错误产生。否则可能只是测试了MySQL检测语法错误的速度了。基准测试完成后，一定要检查一下错误日志，这应当是基本的要求。
9.  忽略了系统预热（warm up）的过程。例如系统重启后马上进行测试。
10. 使用默认的服务器配置。
11. 测试时间太短。基准测试需要持续一定的时间。  
    只有避免了上述错误，才能走上改进测试质量的漫漫长路。  
    如果其他条件相同，就应努力使测试过程尽可能地接近真实应用的情况。当然，有时候和真实情况稍有些出入问题也不大。

## 设计和规划基准测试 ##

*  规划基准测试的第一步是提出问题并明确目标。然后决定采用标准的基准测试还是设计专门的基准测试。
 *  如果采用标准的基准测试，应该确认选择了合适的测试方案。例如，不要使用TPC-H测试电子商务系统。在TPC的定义中，“TPC-H是即席查询和决策支持型应用的基准测试”，因此不适合用来测试OLTP系统。
 *  设计专门的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照，并且该快照很容易还原，以便进行后续的测试。
 *  然后，针对数据运行查询。可以建立一个单元测试集作为初步的测试，并运行多遍。但是这和真实的数据库环境还是有差别的。更好的办法是选择一个有代表性的时间段，比如高峰期的一个小时，或者一整天，记录生产系统上的所有查询。如果时间段选得比较小，则可以选择多个时间段。这样有助于覆盖整个系统的活动状态，例如每周报表的查询、或者非峰值时间运行的批处理作业。
 *  可以在不同级别记录查询。例如，如果是集成式（full-stack）基准测试，可以记录Web服务器上的HTTP请求，也可以打开MySQL的查询日志（Query Log）。
 *  应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。文档规范可以很简单，比如采用电子表格（spreadsheet）或者记事本形式，也可以是复杂的自定义的数据库。需要记住的是，经常要写一些脚本来分析测试结果，因此如果能够不用打开电子表格或者文本文件等额外操作，当然是更好的。

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

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

一个简单的测试规则，就是等系统看起来稳定的时间至少等于系统预热的时间。

一个个常见的错误的测试方式是，只执行一系列短期的测试，比如每次60秒，并在此测试的基础上去总结系统的性能。

## 获取系统性能和状态 ##

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

## 获得准确的测试结果 ##

获得准确测试结果的最好办法，是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？例如，是否对一个I/O密集型（I/O-bound）的应用，采用了CPU密集型（CPU-bound）的测试标准来评估性能？

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

通常来说，自动化基准测试是个好主意。这样做可以获得更精确的测试结果。因为自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。另外也有助于归档整个测试过程。  
自动化的方式有很多，可以是一个Makefile文件或者一组脚本。脚本语言可以根据需要选择：shell、PHP、Perl等都可以。要尽可能地使所有测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。  
一旦设置了正确的自动化操作，基准测试将成为一步式操作。如果只是针对某些应用做一次性的快速验证测试，可能就没必要做自动化。但只要未来可能会引用到测试结果，建议都尽量地自动化。否则到时候可能就搞不清楚是如何获得这个结果的，也不记得采用了什么参数，这样就很难再通过测试重现结果了。

# 基准测试工具 #

没必要开发自己的基准测试系统，除非现有的工具确实无法满足需求。

## 集成式测试工具 ##

集成式测试工具是获得整个应用概况的最佳工具。

*  ab  
    ab是一个Apache HTTP服务器基准测试工具。它可以测试HTTP服务器每秒内最多可以处理多少请求。这是个非常简单的工具，用途也有限，只能针对单个URL进行尽可能快的压力测试。
 *  http\_load  
    这个工具在概念上ab类似，也被设计为对Web服务器进行测试，但比ab更加灵活。可以通过一个输入文件提供多个URL，http\_load在这些URL随机选择进行测试。也可以定制http\_load,使其按照时间比率进行测试，而不仅仅测试最大请求处理能力。
 *  JMeter  
    JMeter是一个java应用程序，可以加载其他应用并测试其性能。不仅可以测试Web应用，也可以测试如FTP服务器，或者通过JDBC进行数据库查询测试。  
    JMeter复杂的多，如可以控制预热时间等参数，根据灵活的模拟真实用户的访问。JMeter拥有绘图接口 （带有内置的图形化处理的功能），还可以对测试结果进行记录，然后离线重演测试结果。

## 单组件式测试工具 ##

有一些有用的工具可以测试MySQL和基于MySQL的系统的性能。

*  mysqlslap  
    可以模拟服务器的负载，并输出计时信息。它包含在MySQL5.1的发行包中。测试时可以执行并发连接数，并指定SQL语句。
 *  MySQL Benchmark Suite(sql-bench)  
    在MySQL的发行包中提过了一套自己的基准测试套件，可以用于在不同数据库服务器上进行比较测试。  
    它是单线程的，主要用于测试服务器只I型那个查询的速度。结果会显示那种类型的操作在服务器上执行的更快。  
    这个测试套件的主要好处是包含了大量预定义的测试，容易使用，所以可以很轻松地用于比较不同存储引擎或者不同配置的性能测试。其也可以用于高  
    层次测试，比较两个服务器的总体性能。  
    这个套件的最大缺点主要有：它是单用户模式的，测试的数据集很小且用户无法使用指定的数据，并且同一个测试多次运行的结果可能会相差很大。
 *  Super Smark  
    是一款用于MySQL和PostSQL的基准测试工具，可以提供压力测试和负载生成。它复杂而强大，可以模拟多用户访问，可以加载测试数据到数据库，并支持随机数据填充数据库。
 *  sysbench  
    是一款多线程系统压测工具。它可以根据影响数据库服务器性能的各个因素来评估系统的性能。ysbench支持Lua脚本语（[http://www.lua.org][http_www.lua.org]），Lua对于各种测试场景的设置可以非常灵活。sysbench是我们非常喜欢的一种全能测试工具，支持MySQL、操作系统和硬件的硬件测试。

## MySQL的BENCHMARK()函数 ##

MySQL有一个内置的BENCHMARK()函数，可以测试某些特定操作的执行速度。参数是执行的次数和表达式。表达式可以是任何的标量表达式（比如返回值是标量的子查询或者函数）。执行的结构永远是0，可以通过客户端返回的时间来判断执行的时间。  
这个函数只是简单的返回服务器执行表达式的时间，不会涉及到分析和优化的开销。表达式必须包含用户变量，否则多次执行的表达式会因为系统缓存命中而影响结果。  
当执行1000次和执行1次的时间一样，第一反应应该是命中缓存了或者出错了。

**参考：<高性能MySQL>**

[http_www.lua.org]: http://www.lua.org