基准测试是针对系统设计的一种压力测试.通常目标是是为了掌握系统的性能,或是重现某个系统状态,或是做新硬件的可靠性测试.
1 为什么做基准测试
基准测试是唯一方便有效的,可以了解系统在给定的工作负载下会发生什么的方法.基准测试可以挂差系统在不同压力下的行为,评估系统的容量,掌握会发生哪些变化,系统如何如何处理不同类型的数据.
基准测试可以在实际负载之外创造一些虚构场景进行测试.基准测试可以完成:
- 验证基于系统的一些假设,确认这些假设是否符合当前的情况
- 重现系统中的某些异常行为,已解决这些异常
- 测试系统当前的运行情况.
- 模拟比当前系统更高的负载,已找出随着压力增大,会遇到的瓶颈
- 规划未来的业务增长,评估在未来项目的负载下,需要什么样的硬件,需要多大容量的网络.这样有助于降低系统升级和重大变更的风险
- 测试应用适应可变环境的能力,可以发现系统在随机并发值下的性能表现,或是在不同配置服务器之间的性能差异.
- 测试不同硬件,软件和操作系统的配置,比如RAID5还是RAID10更适合当前系统
- 证明采购的设备是否配置正确
- 创建单元测试
基准测试的主要问题在于其不是真是压力的测试.基准测试时间给系统的压力相对与真实压力来说,通常比较简单.真是压力是不可预测且变化多端的,有时候会过于复杂二难以解释.所以使用真是压力测试,可能难以从结果中分析出正确的结论
及注册时的压力和真实压力的不同:很多因素会影响基准测试,比如数据量,数据,和查询分布,最重要的是基准测试通常要求尽快的让任务执行完成,所以通常给系统造成过大的压力.
基准测试只能大概的测试,确定系统大致有多少余量(就是能够承受多少峰值的TPS).
2 基准测试的策略
基准测试主要有两种策略:
- 集成式:针对整个系统的整体测试
- 单组件式:单独测试MySQL
集成式测试通常是因为:
- 测试整个应用系统,包括web服务器,应用代码,网络和数据库.因为用户关注的不仅仅是MySQL本身的性能,而是应用整体的性能
- MySQL并非总是应用的瓶颈,因此通过整体测试可以揭示这一点
- 只有对应用做整体测试,才能发现各部分之相互的影响
- 更能揭示应用的真是表现.
但是集成式的基准测试难以建立,甚至很难正确设置,如果设计不合理,就无法反应真实情况.
单组件测试通常因为:
- 需要对比不同的情况下schema或是查询的性能
- 针对应用中的某个具体的问题进行测试
- 避免漫长的基准测试,通过一个短期的基准测试,来反应整体性能
设置真是数据的基准测试复杂耗时.如果想测试应用在规模扩张后的性能表现,就只能通过模拟大量的数据和压力来进行.
3 测试目标
测试目标决定了选择什么样的测试工具和奇数.
是时候需要不同的方法测试不同的指标:
3.1 吞吐量
吞吐量是指单位时间内的事务处理数,这一直是经典的数据库应用测试指标.测试标准如:TPC-C
这类基准测试主要针对在线事务处理(OLTP)的吞吐量,适用于多用户交互式的应用.
常用的测试单位是每秒的事务处理时TPS,优势也采用每分钟的事务处理时(TPM)
3.2 响应时间或是延迟
响应时间用于测试完成一个任务所需要的整体时间,根据具体的引用,测试时间的单位都有可能.根据不同的时间单位可以计算出平均响应时间,最小响应时间,最大响应时间和所占的百分比.
最大响应时间通常意义不大.通常使用百分比响应时间来代替最大响应时间,例如95%的响应时间都是5ms
使用图表有助于解释测试结果,可以将测试结果绘制成折线图,或是散点图,直观的变相数据结果集的分布情况
3.3 并发性
并发性通常标识多少用户在同一时间浏览访问,单位是多少个会话.但是http是无状态的,因此web服务器的并发性更准确的并发性描述是,单位时间内有多少同时发生的并发请求.
应用在不同环节都可以测试并发性.web服务器的高并发,一般导致数据库的高并发,但是服务器采用的语言或是工具集都会对数据库有影响.因此一个设计良好的应用,同事可以打开上百个MySQL数据库服务器链接,但是同时应该只有少数几个链接有实际的查询工作.也就是说,web服务器应该做到,由上百个用户访问时,只有十几个并发请求到达数据库.
并发性基准测试关注的是正在工作中的并发操作,或是同时工作中的线程数或是连接数,当并发性正驾驶,需要测试吞吐量是否下降,响应时间是否变长.
3.4 可拓展性
可扩展性是给系统增加一倍的工作,在理想的情况下应该吞吐量增加一般,或是在给系统增加一半的硬件资源,那么可以获得两倍的吞吐量.
在系统业务压力可能发生变化的情况下,测试可扩展性就十分必要.
可扩展性指标对于容量规范非常有用,可以提供其他测试无法提供的信息来帮助发现应用的瓶颈.
4 基准测试方法
基准测试中,下面这些错误可能导致测试结果不准确:
- 使用真是数据的子集
- 使用错误的数据分布
- 在多用户场景中值做单用户测试
- 在单服务器上测试分布式应用
- 与真实用户行为不匹配
- 没有检查错误.
- 忽略了系统预热的过程:系统重启后需要一段时间才能达到正常的系统荣烺.需要注意预热时间
- 使用服务器的默认配置
- 测试时间太短
4.1 设计和规划基准测试
规划基准测试的第一步是提出问题病明确目标.然后决定采用标准基准测试还是设计专用的测试.
如果是标准的基准测试,应该确认选择合适的测试方案.
设计准用的基准测试很复杂,需要一个迭代的过程,首先需要获得产生数据的快照,并且该快照容易还原,以便后续的测试.
可以在不同级别记录查询(也就是一次基准测试,同时记录集成式和单组件是的结果)
即使不需要创建专用的基准测试,也需要详细的记录测试规划.测试可能需要反复的运行,因此需要精确的重复测试过程.
4.2 基准测试运行时间
基准测试应该运行足够长的时间.因为系统预热.
如果需要测试系统的稳定状态下的性能,那么需要达到这个稳定性状态,因此可能需要非常长的试讲.
大部分系统都会有一些应对突发情况的余量,能够吸收性能尖峰,将一些工作延迟到高峰期之后执行.
系统预热以后,IO活动可能在三四个小时趋向稳定
4.3 获取系统性能状态
需要编写脚本,使用工具来获取当前系统的cpu,IO,内存等数据.
4.4 精确地测试结果
获取精确测试结果需要:
- 正确的基准测试
- 测试数据正确
- 测试标准正确
- 测试结果可重复
- 测试时,系统的状态一致
- 测试时,系统的配置正确.MySQL的默认配置测试没有意义.默认配置是基于消耗很少内存的绩效应用.
4.5 结果分析
通常来说自动化测试可以获取更精确的测试结果,可以防止测试过程中测试人员的偶尔遗漏步骤或是误操作.
通常使用脚本语言编写自动化测试过程.
将性能按照时间顺序绘制成图标,利于分析.
5 基准测试工具
如果没有必要开发自己的基准测试系统,可以使用如下的测试工具.
5.1 集成测试工具
ab,webbench,http_load,tcp_copy
5.2 单组件式测试工具
MySQLlslap:可以模拟服务器的负载,输出即使信息.
MySQL benchmark suite
super smack
database test suit
percona's tpcc-MySQL tool
sysbench
5.3 MySQL内置函数
benchmark(次数,命令)
6 测试用例
跳