目录
1. 集成式(full-stack):对整个系统进行基准测试
2. 单组件式(single-component):单独(对MySQL)进行基准测试
一、进行基准测试的目的(以对MYSQL进行基准测试为例)
对MYSQL进行基准测试呢,主要是为了达到以下的目的。
(1)建立MYSQL服务器的性能基准线。这主要是为了测试MYSQL的服务器的当前运行情况,如果是不清楚当前的性能,我们就无法确认某些优化的实际产生的效果会是怎样,同时我们也可以利用历史基准测试的结果来分析,诊断一些性能中出现的一些问题。
(2)模拟比当前系统更高的负载,以找出系统的压力增加而可能找到的一种系统瓶颈。通常是我们在有一定数据量的情况下,不断地增加数据库的并发,观察QPS,TPS的变化,以判断数据库当前的配置的多少并发情况下是最好的,但是一旦超过了某个并发,可能就会出现性能下降的情况。
(3)测试不同的硬件、软件和操作系统配置的情况下,数据库的性能。比如RAID5,RAID10,那种更适合我们当前的系统。如果系统从机械硬盘升级到SSD这种的负载存储,对随机系统有什么帮助,Linux下不同的分区格式和数据库性能是否会有影响,升级MYSQL的版本是否能够改善性能,对当前数据采用不同的引擎,会对我们的系统会有什么样的影响,所有这类问题,我们都可以通过基准测试来解决。
(4)判断新采购的硬件设备配置是否正确。在新的硬件系统上线到生产环境之前呢,我们一定要对这个新的系统进行基准测试,这不仅可以帮助我们了解新的硬件系统的性能基本线,还可以帮助我们测试当前新的系统,是否存在是否由于配置错误而造成性能不如我们预期的情况的发生。
二、基准测试的策略
1. 集成式(full-stack):对整个系统进行基准测试
(1)优点:
能够测试整个系统的性能,包括web服务器缓存、数据等;
能反映出系统中各个组件接口间的性能问题,体现真实性能状况;
(2)缺点:测试设计复杂,消耗时间长。
2. 单组件式(single-component):单独(对MySQL)进行基准测试
(1)优点:测试设计简单,所需耗费时间短(有时候不需要了解整个系统的情况,而只需要关注单独应用的性能,至少项目初期可以这样做);
(2)缺点:无法全面了解整个系统的性能基线。
三、测试指标
开始基准测试甚至是设计基准测试之前,需要先明确测试的目标,决定选择什么样的测试工具和技术,以获取精确而有意义的测试结果。
1.吞吐量
吞吐量指的是单位时间内的事务处理数量。主要针对在线事务的吞吐量,非常适合多用户的交互式应用。常用测试单位是每秒事务数(TPS)和每分钟事务数(TPM)。
2.响应时间
这个指标用于测试任务所需的整体时间。根据具体应用,测试渐渐单位可能是微秒、毫秒、秒或分钟。根据不同的时间单位,可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间通常意义不大,因为测试时间越长,最大响应时间可能越大。而其结果不可重复,每次测量可能得到不同的最大响应时间。因此,通常可以使用百分比响应时间(percentile response time)来代替最大响应时间。例如,如果95%的响应时间都是5毫秒,则表示人物的95%的时间都可以在5毫秒内完成。
3.并发性
并发性是一个非常重要又经常被被误解和误用的指标。例如,它经常被表示成多少用户在同一时间浏览一个Web站点,经常使用的指标是有多少个回话。然而,HTTP协议是无状态的,大多数用户只是简单的读取浏览器上显示的信息,这并不等同于Web服务器的并发性。而且,Web服务器的并发性也不等同于数据库的并发性,而仅仅只表示回话存储机制可以处理多少数据的能力。Web服务器的并发性更准确的度量指标,是任意时间有多少同时发生的并发请求。
在应用的不同缓解,都可以测量响应的并发性。Web服务器的高并发,一般会导致数据库的高并发,但服务器采用的语言和工具集对此都会有影响。注意不要将创建数据库链接和并发性搞混淆。
一个设计良好的应用,可以同时打开成百上千个数据库链接,但可能只有少数连接在执行。所以说,一个Web站点”同时有50000个用户“访问,却可能只有10~15个并发请求道数据库。
换句话说,并发性基准测试关注的是正在工作中的并发操作,或者是同时工作中的线程数或者连接数。当并发性增加时,需要测试吞吐量是否下降,响应时间是否边长,如果是这样,应用可能就无法处理峰值。
并发性的测试完全不同于响应时间和吞吐量。它不想一个结果,而更像是设置基准测试的一种属性。并发测试通常不是为了测试应用能达到的并发度,而是为了测试应用在不同并发下的性能。
4.可扩展性
在系统的业务压力可能发生变化的情况下,测试可扩展性就非常重要了。简单的说,可扩展性指的是,给系统增加一倍的工作,在理想情况下,能够获得两倍的结果(即吞吐量增加一倍)。或者说,给系统增加一倍的资源(比如两倍的CPU),就可以获得两倍的吞吐量。当然,同时吸能(响应时间)也必须在可以介绍的范围内。大多数系统无法做到如此理想的线性扩展。随着压力的变化,吞吐量和性能都可能越来越差。
可扩展性指标对于容量规划非常有用,它可以提供其他基准测试无法系统的信息。比如系统是基于单个用户的响应时间测试(这是一个很糟糕的测试策略)设计的,虽然测试的结果很好,但并发度增加时,系统的性能有可能变得非常糟糕。而一个不断增加爱用户连接的情况下的响应时间测试则可以发现这些问题。
归根结底,应该测试那些对用户来说最重要的指标。因此应该尽可能的收集一些需求,比如,什么样的响应时间是可以介绍的,期待多少并发性,等等。然后基于这些需求来设计基准测试,避免目光短浅的只关注部分指标,忽略其他指标。