实操展示：基准测试案例解析

现在我们已经知道了什么是基准测试,以及在基准测试中,所需要关注的指标都有什么,现在我们就来看一看

进行一个具体的基准测试,所需要的步骤,首先我们要对我们的基准测试有一些规划和设计,基准测试的设计呢,

要可能的简单,那这一步呢,我们要明确我们要采用的基准测试方式是哪一种,是对整个系统来进行基准测试呢,

还是对某一个组件,比如对MYSQL进行基准测试就可以了,另外呢,还要确定我们要使用什么样的数据,来进行基准

测试,比如,我们希望基准测试呢,能够反映出系统的基本情况,那么最好呢,就可以使用生产环境的实际数据,和

所进行的SQL呢,来完成基准测试,如果我们要使用这种方式呢来进行测试的话,就要注意了,我们最好是利用生产

环境数据库的备份,以及在一定时间内,实际所产生的SQL日志,来运行这种多线程的回放,来完成这种测试,这种方式呢,

相对来说是比较复杂,并且所要准备数据的时间呢,和测试时间呢都会比较长,而如果我们只想知道某个参数的调整,

对我们数据库性能的影响的话,就完全没有必要这么麻烦,我们可以使用专门的测试工具来生成测试中所需要的数据

和SQL,以此来完成我们的基准测试,这种方法呢比我们使用生产环境的数据呢,要更加的简单,我们下面的演示中呢,

也是使用第二种方法,在这一步中呢,还要计划好,我们基准测试所要运行的时间和次数,通常情况下,如果我们对基准测试

只运行一次,很短时间的话呢,我们想象的测试结果呢,是实时的,就是没有任何参考意义的,我们只有多次测试之后,

取得平均的测试结果,这样才能反映我们系统的真实性能

那么第二步呢,就是要准备好在测试中,需要使用的测试数据,和一些系统状态信息的收集脚本,对于测试数据

的准备呢,前面我说过了,如果希望使用系统的真实数据的话,那么我们最好呢,要提前获取真实数据的数据备份,

以及在真实环境中,运行SQL的一个记录,对于SQL执行的一个记录呢,通常我们可以通过把慢查日志全部记录下来

的方式呢,来获得,如果我们的测试没有必要使用真实数据的话,一般的这种测试工具呢,都可以提供测试工具的生成,

以及SQL脚本生成的功能,但是对于测试执行过程中,系统状态收集的脚本,就需要我们自己来编写了,正常情况下在

执行一个基准测试时,我们需要尽可能多的呢,收集系统的当前信息,包括CPU使用率,磁盘IO,网络流量的统计信息,

以及MYSQL的innodb状态的计数器信息的相关信息等等,这里呢,我为大家准备了一个脚本,大家可以根据脚本呢,再

根据你的需求呢,来创建一个脚本,达到我们收集系统信息的目的,那么我们下面就来看看这个脚本

Get_Test_info.sh,就是我们信息收集的脚本,我们来看看这个脚本的内容

vim Get_Test_info.sh

我们来看看这个脚本很简单,在前面两行就定义了,脚本的运行间隔,每隔多长时间我就收集一下状态信息,

第三行我们就定义了,我们把我们的动态信息,收集到什么位置,就是记录到什么目录下,第四行就指定了一个

运行标识,就是如果存在这个标识呢,就证明我们这个脚本在运行,如果你想停止这个脚本呢,可以通过删除这个

标识文件的方式呢来停止我们这个信息收集的脚本,第五行就是我们实际生成的运行标识的一个文件,第六行指定

了我们MYSQL的命令行,MYSQL命令所在的位置,第七行就是记录了运行了测试当前MYSQL系统的设置信息,从第八行

开始,就是一个循环,这个循环呢只要在我们刚才所说的那个标识文件存在的情况下呢,就会一直的循环下去,第九行

到11行呢,也就是定义了我们脚本的运行时间,文件名,还有我们每隔多长时间运行这个脚本,那么第13行呢,就收集

到了我们系统的负载情况,并把它记录到了一个文件中,第15行呢,是收集的是MYSQL的,全局的状态信息,同样的会把它

记录到一个文件中,第17行收集到的是innodb的状态信息,第19行呢,收集到了MYSQL当前连接的线程的情况,涉及到了我们

MYSQL在基准测试时系统信息

基本上就已经很全了,当然大家也可以根据自己的需要,在准备好我们需要的测试数据,以及系统收集脚本,

我们就可以开始我们实际的测试了,由于我们的测试会多次执行,如果可以编写脚本呢,多次测试的过程呢,

肯定是最方便的,其实这个脚本很简单,这里就不演示循环怎么编写了,我们可以通过自己测试的步骤呢,编写这个

脚本,不过呢一定要注意,我们在这个脚本中呢,同时记录下每次运行的信息,以便我们后面的分析使用,完成了基准

测试呢,最后一步就是要对我们测试过程中,所收集的信息来进行分析,以便看我们的调整是否有效,在这个过程中呢,

同样需要自己编写,相关的脚本,来进行更多信息的一种处理,并且最好可以通过图形的方法呢来展示我们的测试结果,

这里我也提供了一个简单的测试脚本,我们先回来看一下

vi analyze.sh

一共只有18行,这个脚本实际上呢,分析了我们刚才所收集的MYSQL全局状态的信息的文件,并且取出了每一次,

执行的间隔,间隔多长时间,并且打印出了我们当前系统的load值,以及这里查询的数量,也就是说,每一次在

MYSQL状态信息中,所查询的数量,通过两次数量的差,除以时间间隔呢,可以得到我们刚才说的QPS,我觉得每秒钟

查询的数量,这么一个统计结果,当然呢大家也可以根据你自己的需要来扩充这个脚本,我们可以把它改写成来统计

TPS,或者每秒插入量,删除量,更新量的脚本,同时也可以通过MYSQL的状态变量呢,知道我们每一次,运行这个参数时呢,

并发量是什么样子的,或者是线程量是多少,我们都可以通过这个脚本来完成那在进行具体演示之前呢,我们还要来看一下

在基准测试中,我们需要注意的一些问题,只有避免了这些问题呢,我们的基准测试才是准确的,才能体现出我们的实际性能,

我们在进行基准测试时呢,一定要注意以下几个问题,这些问题呢,都有可能导致我们的基准测试不正确,首先第一个可能被

我们忽视的问题呢,就是使用生产环境的真实数据进行基准测试时,我们只使用了真实数据的一个子集,而不是全部的生产

环境数据,前面讲解如何使用基准测试,我提到过,如果我们希望使用生产环境的数据,来进行基准测试,那最好是使用生产

环境数据库完全的备份,来进行测试,而不是人为的从全部数据中选择出一小部分数据呢来进行测试,比如说我们的真实环境中,

数据库有几百个G的数据,而我们在测试时呢,为了方便,人为的选择了几个G的子集,这样进行测试呢,是不能真实的反映系统的

情况的,而且我们认为的选择了数据呢,不能完全体验出,生产环境中真实数据的情况,这样得出的结果呢,很可能是不正确的了,

第二个被我们经常忽视的问题就是,在一个多用户的场景中,我们只使用单用户的模式来进行测试,比如我们的WEB应用,同时是

大量用户并发的使用场景,所以对于WEB应用呢,数据库来进行基准测试时呢,一定要考虑到并发的情况,使用多个连接线程呢,

MYSQL性能来进行测试,通常情况下,多线程的并发的数据库性能,单线程数据库访问的表现是完全不同的,应用在单线程的时候呢,

可能会应用的很好,但是一旦存在了并发的情况呢,就会出现大量的阻塞和死锁,这些问题呢,在单线程的测试中呢,是无法发现的,

所以我们要根据应用的实际情况,来进行我们测试的设计,而对于多用户使用的场景呢,一定要使用多线程的并发测试,才能达到

我们想要的目的,而另一个和上面有点类似的情况呢,分布式应用的性能,分布式的表现,跟单服务器是完全的不同的,比如我们的生产

环境中,数据库部署呢,可能使用的是主从同步,那么在进行基准测试时呢,也要使用相同的架构来进行测试,因为一方面来说,

通常情况下,读写分离,所使用的中间层,会有性能损耗,如果我们在基准测试时,不考虑中间层的性能损耗,测试结果就很难用于

预估我们生产环境中的性能,这时候我们就会发现,我们数据库在基准测试环境,性能远好于我们实际的生产环境,这样存储结果呢,

也无法为我们的优化生产环境的性能呢,没有任何的帮助,那么最后一个容易让我们忽视的问题呢,在测试过程中呢,反复的执行

同一个查询,在真实的生产环境中,查询肯定是不尽相同的,这可能会造成查询缓存的命中率呢,比较低的情况,而我们在基准测试

中,反复的使用相同SQL来查询,那么在某种程度上来说呢,这个查询可能完全会在缓存中命中,所以就无法真实的反应查询的真实

性能,以上就是我们在基准测试时呢,需要避免和注意到的一些问题