第02章 MySQL基准测试

标签：记录   相互   指标   测试用例   防止   http   活动   不同   可靠   

基准测试是针对系统设计的一种压力测试.通常目标是是为了掌握系统的性能,或是重现某个系统状态,或是做新硬件的可靠性测试.

1 为什么做基准测试

基准测试是唯一方便有效的,可以了解系统在给定的工作负载下会发生什么的方法.基准测试可以挂差系统在不同压力下的行为,评估系统的容量,掌握会发生哪些变化,系统如何如何处理不同类型的数据.

基准测试可以在实际负载之外创造一些虚构场景进行测试.基准测试可以完成:

1. 验证基于系统的一些假设,确认这些假设是否符合当前的情况
2. 重现系统中的某些异常行为,已解决这些异常
3. 测试系统当前的运行情况.
4. 模拟比当前系统更高的负载,已找出随着压力增大,会遇到的瓶颈
5. 规划未来的业务增长,评估在未来项目的负载下,需要什么样的硬件,需要多大容量的网络.这样有助于降低系统升级和重大变更的风险
6. 测试应用适应可变环境的能力,可以发现系统在随机并发值下的性能表现,或是在不同配置服务器之间的性能差异.
7. 测试不同硬件,软件和操作系统的配置,比如RAID5还是RAID10更适合当前系统
8. 证明采购的设备是否配置正确
9. 创建单元测试

基准测试的主要问题在于其不是真是压力的测试.基准测试时间给系统的压力相对与真实压力来说,通常比较简单.真是压力是不可预测且变化多端的,有时候会过于复杂二难以解释.所以使用真是压力测试,可能难以从结果中分析出正确的结论

及注册时的压力和真实压力的不同:很多因素会影响基准测试,比如数据量,数据,和查询分布,最重要的是基准测试通常要求尽快的让任务执行完成,所以通常给系统造成过大的压力.

基准测试只能大概的测试,确定系统大致有多少余量(就是能够承受多少峰值的TPS).

2 基准测试的策略

基准测试主要有两种策略:

1. 集成式:针对整个系统的整体测试
2. 单组件式:单独测试MySQL

集成式测试通常是因为:

1. 测试整个应用系统,包括web服务器,应用代码,网络和数据库.因为用户关注的不仅仅是MySQL本身的性能,而是应用整体的性能
2. MySQL并非总是应用的瓶颈,因此通过整体测试可以揭示这一点
3. 只有对应用做整体测试,才能发现各部分之相互的影响
4. 更能揭示应用的真是表现.

但是集成式的基准测试难以建立,甚至很难正确设置,如果设计不合理,就无法反应真实情况.

单组件测试通常因为:

1. 需要对比不同的情况下schema或是查询的性能
2. 针对应用中的某个具体的问题进行测试
3. 避免漫长的基准测试,通过一个短期的基准测试,来反应整体性能

设置真是数据的基准测试复杂耗时.如果想测试应用在规模扩张后的性能表现,就只能通过模拟大量的数据和压力来进行.

3 测试目标

测试目标决定了选择什么样的测试工具和奇数.

是时候需要不同的方法测试不同的指标:

3.1 吞吐量

吞吐量是指单位时间内的事务处理数,这一直是经典的数据库应用测试指标.测试标准如:TPC-C

这类基准测试主要针对在线事务处理(OLTP)的吞吐量,适用于多用户交互式的应用.

常用的测试单位是每秒的事务处理时TPS,优势也采用每分钟的事务处理时(TPM)

3.2 响应时间或是延迟

响应时间用于测试完成一个任务所需要的整体时间,根据具体的引用,测试时间的单位都有可能.根据不同的时间单位可以计算出平均响应时间,最小响应时间,最大响应时间和所占的百分比.

最大响应时间通常意义不大.通常使用百分比响应时间来代替最大响应时间,例如95%的响应时间都是5ms

使用图表有助于解释测试结果,可以将测试结果绘制成折线图,或是散点图,直观的变相数据结果集的分布情况

3.3 并发性

并发性通常标识多少用户在同一时间浏览访问,单位是多少个会话.但是http是无状态的,因此web服务器的并发性更准确的并发性描述是,单位时间内有多少同时发生的并发请求.

应用在不同环节都可以测试并发性.web服务器的高并发,一般导致数据库的高并发,但是服务器采用的语言或是工具集都会对数据库有影响.因此一个设计良好的应用,同事可以打开上百个MySQL数据库服务器链接,但是同时应该只有少数几个链接有实际的查询工作.也就是说,web服务器应该做到,由上百个用户访问时,只有十几个并发请求到达数据库.

并发性基准测试关注的是正在工作中的并发操作,或是同时工作中的线程数或是连接数,当并发性正驾驶,需要测试吞吐量是否下降,响应时间是否变长.

3.4 可拓展性

可扩展性是给系统增加一倍的工作,在理想的情况下应该吞吐量增加一般,或是在给系统增加一半的硬件资源,那么可以获得两倍的吞吐量.

在系统业务压力可能发生变化的情况下,测试可扩展性就十分必要.

可扩展性指标对于容量规范非常有用,可以提供其他测试无法提供的信息来帮助发现应用的瓶颈.

4 基准测试方法

基准测试中,下面这些错误可能导致测试结果不准确:

1. 使用真是数据的子集
2. 使用错误的数据分布
3. 在多用户场景中值做单用户测试
4. 在单服务器上测试分布式应用
5. 与真实用户行为不匹配
6. 没有检查错误.
7. 忽略了系统预热的过程:系统重启后需要一段时间才能达到正常的系统荣烺.需要注意预热时间
8. 使用服务器的默认配置
9. 测试时间太短

4.1 设计和规划基准测试

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

如果是标准的基准测试,应该确认选择合适的测试方案.

设计准用的基准测试很复杂,需要一个迭代的过程,首先需要获得产生数据的快照,并且该快照容易还原,以便后续的测试.

可以在不同级别记录查询(也就是一次基准测试,同时记录集成式和单组件是的结果)

即使不需要创建专用的基准测试,也需要详细的记录测试规划.测试可能需要反复的运行,因此需要精确的重复测试过程.

4.2 基准测试运行时间

基准测试应该运行足够长的时间.因为系统预热.

如果需要测试系统的稳定状态下的性能,那么需要达到这个稳定性状态,因此可能需要非常长的试讲.

大部分系统都会有一些应对突发情况的余量,能够吸收性能尖峰,将一些工作延迟到高峰期之后执行.

系统预热以后,IO活动可能在三四个小时趋向稳定

4.3 获取系统性能状态

需要编写脚本,使用工具来获取当前系统的cpu,IO,内存等数据.

4.4 精确地测试结果

获取精确测试结果需要:

1. 正确的基准测试
2. 测试数据正确
3. 测试标准正确
4. 测试结果可重复
5. 测试时,系统的状态一致
6. 测试时,系统的配置正确.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 测试用例

跳

第02章 MySQL基准测试

标签：记录   相互   指标   测试用例   防止   http   活动   不同   可靠   

原文地址：https://www.cnblogs.com/perfy576/p/9161829.html