就是针对系统设计的一种压力测试,是唯一方便有效的、可以学习系统在给定的工作负载下会发生什么方法。基准测试毕竟不是真实压力测试,所以做基准测试只能说是进行大概的测试,来确定系统大致的余量,其要求尽量简单直接,结果之间容易相互比较,成本低且易于执行
测试策略
有两种主要的策略:一是针对整个系统的整体测试,另一个是单独测试MySQL。其中对整个系统做集成式测试而不单独测试MySQL的原因是:
1. 用户不仅仅关注的是MySQL本身性能,而更多的是应用整体性能
2. MySQL并非总是应用的瓶颈,通过整体测试可以揭示这点
3. 对整体测试才会发现各部分之间的缓存带来的影响
4. 更能揭示应用的真实表现
而由于对整体做基准测试很难建立,有时候其实只需要关注MySQL本身的性能,至少项目初期可以这么做,以下情况选择只测试MySQL:
1. 需要比较不同的schema或查询的性能
2. 针对应用中某个具体问题的测试
3. 为毕淼漫长的基准测试,想通过一个短期的基准测试来检测某些调整后的效果
测试指标
吞吐量:单位时间内的事务处理数。常用的测试单位是每秒事务数(TPS)或者分钟事务数(TPM)。
响应时间或者延迟:用于测试任务所需的整体时间。根据时间可以计算出平均响应时间、最小最大响应时间和所占百分比。
并发性:这里数据库的并发性并不是同时创建的连接数,而是同时执行的查询数,换言之关注的是正在工作中的并发操作,或者是同时工作中的线程数或者连接数。当并发性增加时,需要测量吞吐量是否下降,响应时间是否变长,如果是这样,应用可能就无法处理峰值压力。并发性测试通常不是为了测试应用能达到的并发度,而是为了测试不同并发度下的性能。数据库的并发性需要测量,可以通过sysbench指定32、64或128个线程测试,然后测试期间记录MySQL的Threads_running状态值。
可扩展性:指给系统增加一倍的工作,在理想情况下就能获得两倍的结果(即增加一倍吞吐量),同时性能(响应时间)必须在可接受的范围内。
测试方法
如下错误可能导致测试结果无用或者不准确:
使用真实数据的子集而不是全集,没有结合实际的数据需求来
使用错误的数据分布,数据分布状态要符合真实数据的特点
使用不真实的分布参数,数据读取特点不符合实际
多用户场景下只做单用户测试
单服务器上测试分布式应用
与真实用户行为不匹配
反复执行同一个查询
没有检查错误,基准测试后一定要检查下错误日志
忽略了系统预热的过程,要了解系统重启后需要多长时间才能达到正常的性能容量
使用默认的服务器配置,没有使用优化的配置
测试时间较短
总之就是要让测试过程尽可能接近真实应用的情况。
要建立将参数和结果文档化的规范,每一轮测试都必须进行详细记录,做好设计和规划。
基准测试应该运行足够长的时间,系统需要预热。(不然会有新版本没有旧版本性能快的错觉)
写些脚本来获取系统性能和状态,建议建立一个目录为每一轮测试都创建单独的子目录,里面保存着测试结果、配置文件、测试指标、脚本和其他说明。
为了确认测试结果是否可重复,每次重新测试之前要确保系统的状态是一致的,如果是非常重要的测试,甚至每次都要重启系统。一般情况下,需要测试的是经过预热的系统,还需要确保预热时间足够长、是否可重复。如果预热采用的是随机查询,那么测试结果可能就不可重复。
很多基准测试都是用来做预测系统迁移后的性能的,如从Oracle迁移到MySQL,很多情况下都需要重新设计MySQL的schema和查询。
基于MySQL的默认配置测试没有什么意义,因为其默认配置是基于消耗很少内存的极小应用,如果直接用其他的商业数据库与MySQL默认配置进行对比测试是很没有说服力的。
运行与结果分析
尽量采取自动化测试,可以使用一个Makefile文件或者一组脚本。
使用集成式的测试工具:
ab:一个Apache HTTP服务器基准测试工具,可以测试HTTP服务器每秒最多可以处理多少请求。如果是针对应用就是整个应用每秒可以满足多少请求,是一个非常简单的工具,但只能针对单个URL尽可能快的压力测试。
http_load:与ab类似,但是可以输入一个文件提供多个URL,对这些URL进行随机选择测试。
JMeter:一个java应用程序,可以加载其他应用并测试其性能。比前两个复杂,可以通过控制预热时间等参数来更加灵活地模拟真实用户的访问,而且有绘图接口,可以记录测试数据,然后离线重演测试结果。
使用单组件测试工具(针对MySQL的):
mysqlslap:可以模拟服务器负载,输出计时信息。测试时可以执行并发连接数量,并指定sql语句。如果没有指定sql,会自动生成查询schema的select语句。
MySQL Benchmark Suite(sql-bench):可以用于不同MySQL数据库服务器上进行比较测试,是单线程的,主要用于测试服务器执行查询的速度,比较哪种类型的操作在服务器上执行得更快。好处是包含大量预定义测试,容易使用,可以很轻松地用于比较不同存储引擎或者不同配置的性能测试,缺点是由于是单线程的,所以无法测试多CPU的能力,只能比较单CPU服务器的性能差别。(该版本5.7已经拿掉了,要学习只能参看5.6版本)
Super Smack:一款用于MySQL和PostgreSQL的基准测试工具,可以提供压力测试和负载生成,是一个强大复杂的工具,可以模拟多用于访问,可以加载测试数据到数据库,并使用随机数据填充测试表。测试定义使用的是.smack文件。
Database Test Suite:一款类似某些工业标准测试的测试工具集。
Percona's TPCC-MySQL Tool:一个类似TPC-C的基准测试工具集,有部分是专门为MySQL测试开发的。(https://www.cnblogs.com/xuanzhi201111/p/4148434.html)
sysbench:一款多线程系统压测工具,可以根据影响数据库服务器性能的各种因素来评估系统性能。功能强大,且支持Lua脚本语言,更加灵活。(https://blog.csdn.net/kikajack/article/details/79977108)
总结
每个MySQL使用者都应该了解一些基准测试的知识,正确描述问题,选择合适基准测试回答问题,设置测试参数,运行,收集,分析。
如果没有做个基准测试的建议至少要熟悉sysbench,可以先学习如何使用oltp和fileio测试。基准测试很重要,比如SAN存储真的出现坏盘,或者RAID控制器的缓存策略的配置不像工具中显示哪有,通过对单磁盘测试如果发现每秒可以执行14000次随机读,那么要么是碰到严重错误或者配置出现问题。(一块机械磁盘每秒只能执行几百次的随机读操作,因为寻道操作需要时间的)