如何进行基准测试

前面我们介绍了什么是基准测试,根据前面的定义我们可以知道,对MYSQL进行基准测试呢,主要是为了达到以下的目的,

首先呢是建立MYSQL服务器的性能基准线,这主要是为了测试MYSQL的服务器的当前运行情况,如果是不清楚当前的性能,

我们就无法确认某些优化的实际产生的效果会是怎样,同时我们也可以利用历史基准测试的结果呢,来分析,诊断一些性能

中出现的一些问题,那么基准测试的第二个目的呢,就是模拟比当前系统更高的负载,以找出系统的压力增加,而可能找到

的一种系统瓶颈,通常是我们在有一定数据量的情况下,不断地增加数据库的并发,观察QPS,TPS的变化,以判断数据库当前

的配置的多少并发情况下是最好的,但是一旦超过了某个并发,可能就会出现性能下降的情况,基准测试还可以帮我们测试

不同的硬件,软件和操作系统,配置的情况下,数据库的性能,比如RAID5,RAID10,那种更适合我们当前的系统,如果系统从

机械硬盘升级到SSD这种的负载存储,对随机系统有什么帮助,Linux下不同的分区格式,和数据库性能是否会有影响,升级

MYSQL的版本是否能够改善性能,对当前数据采用不同的引擎,会对我们的系统会有什么样的影响,所有这类问题呢,我们都

可以通过基准测试来解决,最后呢我们还可以通过基准测试证明我们新采购的硬件设备,是否配置是正确的,在新的硬件系统,

就是上线到生产环境之前呢,我们一定要对这个新的系统进行基准测试,这不仅可以帮助我们了解新的硬件系统的性能基本线,

还可以帮助我们测试当前新的系统,是否存在是否由于配置错误,而造成性能不如我们预期的情况的发生

那么接下来我们看看如何进行基准测试,通常来说,基准测试有两种常见的方法,一种方法是对整个系统进行基准测试,

这种方法呢,一般是从系统的入口进行测试,比如对于网站来说,通常是从WEB前端来进行测试,比如手机APP来说呢,通过

APP的前端来进行测试,这种方法的优点在于,能够测试整个系统的性能,包括WEB服务器,程序代码,网络,缓存服务器和

数据库,等等这些组件,这一点通常来说,是非常重要的,因为我们所关心的呢,并不仅仅是MYSQL服务器的性能,相比于数据库呢,

我们通常更关心整个系统的性能是怎样子的,所以呢,对于整个系统进行整体的测试呢,直接反映出,我们所关心的各种新能问题,

另外呢,从另一方面来说,MYSQL也并非总是系统性能产生这个问题的瓶颈,如果我们只关注MYSQL,可能会忽略其他组建的性能问题,

所以说,对整个系统进行基准测试呢,第二个优点就是,能够反映出系统中各个组件接口间的性能问题,体现真实的性能状况,虽然

对系统进行整体测试有很多的有点,但是其缺点也是不容忽视的,下面我们就来看他的缺点,我们前面提到过,基准测试最重要的

就是要简单,因为我们在系统优化的时候,可能要对不同的基准测试方案进行基准测试,以找出最好的解决方法,所以基准测试进行

的时间要短,否则我们要花大量的时间来进行基准测试,所以对整个系统进行基准测试呢,这种方法的缺点就是,测试设计的比较

复杂,完成一次测试耗费的时间也会很长,通常完成一次对整个系统的性能测试呢耗费几天的准备时间是挺正常的

基准测试的第二种方法呢,单独对某一个组件进行基准测试,特别是在一些时候,你并不需要对整个系统呢,进行基准

测试的情况下,那么呢使用这种测试呢,单独对组件进行基准测试呢,这种方式可能更加的合适了,比如我们只更新了

MYSQL服务器的硬件,或者对于一些MYSQL中的索引啊,SQL进行了优化,这时我们就只需要单独对MYSQL进行必要的基准

测试就可以了,从对整个系统进行基准测试呢,是一样的,这种方法也有其优缺点,我们先来看看单独对MYSQL进行基准

测试的优点都有什么,首先这种方法的优缺点呢,正好对和整个系统进行基准测试的这种优缺点是相反的,尤其是对于

有点来说,他的优点呢就是测试方法设计呢通常比较简单的,相对于测试所耗费的时间呢,也会更短,比较适合用于不同

的数据结构啊,查询性能的差异,或者具体应用的某个问题来进行测试,那么当前其缺点呢,也是显而易见的,就是由于

我们单纯对MYSQL进行测试,所以必然无法全面的了解整个系统的性能基准线,也无法体现出系统中不同组件及接口之间

的性能问题,以上就是我们基准测试常用的两种方法,我们还要知道测试了哪些内容才能反映出性能状态,以及使用什么样

的工具和方法来进行测试,由于我们在这里讨论的是对于MYSQL的进行性能优化,所以呢我们就以第二种测试方式,也就是

单独对MYSQL来进行基准测试的方法呢,来给大家介绍具体的基准测试的方法和工具,以方便大家呢,对优化后的MYSQL

进行测试,下面我们先来对MYSQL性能基准测试常用的指标是有哪些

对于MYSQL数据库来说呢,常见的测试指标呢,大家多少呢也会听过一些,比如单位时间内所处理的事务量,

和查询数量,这两个指标呢主要用于衡量数据库的吞吐量,我们大家所熟悉的数据库,每秒处理的事务量,

TPS,和数据库每秒处理的查询量QPS,就是这类指标的具体体现,对于相同数据量的相同SQL进行测试呢,如果

调整后的TPS量,和QPS量有明显的增长,那我们的调试呢,是成功的,否则我们就要考虑我们的优化方法呢,

是否正确,响应时间是另一个采用的基准测试指标,这个指标用于衡量完成一个测试任务所花费的总体的

时间,一个测试,通常会包括很多的测试项,这在我们对一个SQL进行测试,通常也会对这个SQL执行很多次,

那么具体的测试情况和测试是不同的,这个响应时间单位也可能是微秒,毫秒,秒,或者是分钟,当然呢也

可能是小时,根据不同的时间单位,我们可以计算出,每一次的平均响应时间,最小响应时间,以及最大

响应时间,和各个时间响应所占的百分比,通常这些统计指标,通常来说呢,最大的响应时间呢对我们的

意义并不大,因为随着测试时间的加长,最大响应时间也会越来越大,对我们比较有意义的呢,应该是百分比

响应时间,例如说吧,一个SQL,百分之九十的响应时间呢,是在10毫秒,那么我们就可以认为这个SQL呢,在

正常情况下,他的响应时间就是10毫秒,而超过10毫秒的情况呢,可能是会出现了一些意外,比如一些锁啊,

这种情况造成的响应时间加长,那么另外一个基准测试的重要指标呢,就是并发请求的数量,这个指标经常

会和系统的连接数量想混淆,比方说,对于网站应用来说,这个指标会被经常表示成,有多少用户在同一时间

浏览一个WEB网站,通常会以WEB服务器的会话量来表达这个指标,实际上就是不正确的,比如我们会经常看到

一个比较大的论坛,会显示同时在线的人数呢,有几千甚至上万,但这并不代表,并发数量就有这么多,一方面

对于大多数用于来说,只是简单地浏览WEB页面上显示的信息,这并不等于WEB服务器的并发性,另一方面呢,

服务器的并发量呢也并不等同于数据库的并发量,即使WEB服务器有几千上万的会话,到MYSQL端呢,并发可能

只有几十个,甚至可能会更少,后面我们可能会告诉大家,如何获取MYSQL服务器的并发情况,在这里大家要知道,

并发量基准测试呢,需要关注的是正在工作中的并发的操作数,或者是同时工作的数量,而不是由多少连接的线程

就可以了