一、benchmark概念
在计算中,基准是运行一个计算机程序、一组程序或其他操作的行为,以评估一个对象的相对性能,通常是通过对它运行一些标准测试和试验。
基准测试一词也通常用于精心设计的基准测试程序本身。
基准测试通常与评估计算机硬件的性能特征有关,例如CPU的浮点性能运算性能,但在某些情况下该技术也使用于软件。如,软件基准测试针对编译器或者数据库管理系统(DBMS)运行。
基准测试提供了一种比较不同芯片、系统架构中各种子系统性能的方法。
核心定义:通过设计合理的测试方法,选用合适的测试工具和被测系统,实现对某个特定目标场景的某项性能指标进行定量的和可对比的测试。
二、基准测试的关键点:
. 测试方法:到底使用微基准测试,介基准测试,还是使用宏基准测试,或者是负载测试、压力测试、并发测试、稳定性测试,则需要根据我们的需要选择一个合适的。
. 测试工具:选择合适的测试工具,能更好的精确的测量出我们的数据。
. 某个目标场景:性能测试时,往往需要选择一些场景。比如到底只是达到某个比较低的标准即可,还是想直接把系统压死等等
. 某项性能指标:需要知道这一次到底追求的是哪个性能指标,到底是QPS还是吞吐量,还是TP99,亦或点击数、资源利用率、错误率等等。
. 可对比:用不同的方法或者工具进行多次测试进行数据对比
三、测试方法:
1、微基准测试
微基准测试(Micro-benchmarks)是基准测试中的一种方法,用来测试微小代码单元的性能,通常这个微小代码单元可以是一段算法,一个方法,一个数据结构。
public void test() {
long then = System.currentTimeMills();
for (int i = 0; i < nLoops; i++) {
l = fibImpl(50);
}
System.out.println("use time:" + (System.currentTimeMills() - then));
}
上面是一段测试斐波拉契数列性能的代码,很多人以为用上面的方式就可以测试出fibImpl这个函数的性能,但是结果往往是错误的,通常会有下面一些问题:
. 没有使用函数测试结果,通常如果没有使用结果的话Java可能会将这个代码优化成不会执行fibImpl这个函数。
. 没有预热,在JAVA中被预热编译执行的代码比解释执行的代码性能更好。
. 容易发生OSR(栈上替换),这里我们模拟循环来测试多次fibImpl性能,但是如果发生OSR,那么OSR之后的性能会比之前的更好。
当然还有其他更多的问题这里就不一一介绍了,只是想突出微基准测试有很多容易影响测试结果的地方,同样的微基准测试在做业务开发的时候使用场景也很局限,我们很多时候瓶颈不会是某个算法,某个数据结构,而往往是数据库,网络等等。
2、宏基准测试
宏基准测试(macro-benchmark),顾名思义和上面的测试相反,往往会测试一个应用的整体性能,比如模拟大量的真实用户使用这个应用,从而测试出性能。很多时候我们的全链路压测基本就会对应宏基准测试,测试所需要的的流程以及环境都和真实场景一样,这样才能真正的测试出整个应用性能的问题。在真正的全链路压测的情况下,往往会把真实的请求数据先复制下来,然后收集足够多的数据之后,利用这些真实的数据来进行压测。
3、介基准测试
宏基准测试对于很多场景比较重,这个时候就出现了介基准测试,介基准测试没有要求请求的真实,在整个链路上一些不是很重要的地方在介基准测试中都可以进行忽略,比如登录验证,安全验证等等,将测试的目标聚焦在我们的业务核心上,通过介基准测试能让我们更简便的测试出系统的性能。
4、负载测试
通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。(负载:向服务器发送请求)
负载测试是通过逐步加压的方式来确定系统的处理能力、确定系统能够承受的各项阀值。 例如:逐步加压,从而得到“响应时间不超过3秒”、“服务器CPU平均利用率低于80%”等指标的阀值。
*阀值:关注的某一具体数值(比如:登录小于3秒、用户数2000、业务成功率100%)
5、 压力测试
通过逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于【失效】状态。
压力测试:是逐步增加负载,使系统某些资源达到饱和甚至失效。(如:测试系统最多支持同时处理多少请求,超过此数数量系统瘫痪)
负载测试:是逐步增加负载,确定在满足性能指标情况下,系统能承受的最大负载测试。(如:登录3秒内,最多支持多少用户同时登录;如超出此数量,可能需要5秒钟或更多时间才能登录成功)
6、 并发测试
概念:并发测试就是【多用户】同时访问【同一个应用】。 目的:测试应用服务器指定功能的同时访问数是否达到预期结果。
*并发测试需要配合集合点来使用(集合点:我们在接口阶段已了解)
7、稳定性测试
通过给系统加载一定的业务压力(如:CPU资源在70%~90%的使用率)的情况下,运行一段时间,检查系统是否稳定。
*通常稳定性测试,我们测试一段时间即可;(如:24小时、3×24小时或7×24小时来模拟长时间运行)
四、测试工具
1、Gatling
Gatling是一款基于Scala 开发的高性能服务器性能测试工具,它主要用于对服务器进行负载等测试,并分析和测量服务器的各种性能指标。Gatling主要用于测量基于HTTP的服务器,比如Web应用程序,RESTful服务等。
Gatling对Java选手来说有一定的学习成本,并且Gatling国内好像使用得较少,但是Gatling使用得Akka Actors异步模型,他可以使用少量的线程就能支持高并发,不需要像JMeter一样搭建多个集群去使用。Gatling在我们公司使用得较多,目前只能测试Http相关的,如果要测试rpc相关的需要先将rpc协议转换成Http协议。
2、JMeter
Apache JMeter是Apache组织开发的基于Java的压力测试工具。它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。同时JMeter支持对性能压测结果做图形分析。
JMeter通常是一个模拟用户就是一个线程,当模拟并发数变多的时候性能会下降,通常会搭建一个JMeter集群去模拟并发数较多的情况。
3、全链路压测PTS/自研
上面的方法都不能用来做全链路压测,都缺少很多核心功能,比如请求录制,定时压测,实时监控,报告分析等等,这个时候我们可以直接使用阿里云的PTS进行全链路压测,或者自研一套基于自己业务系统的全链路压测系统。
4、 JMH
我们在第三章介绍了微基准测试编写代码很困难,但是在Java里有一个组件叫做JMH,也就是Java的微基准测试套件,他能帮助你做到下面这些事:
能自动帮助预热
时间精确到纳秒
能更加详细的知道测试数据,平均时间,最大值,TP99等
不需要额外代码编写多线程
5、LoadRunner
HP公司使用C语言开发的一款性能负载测试工具
作用:模拟高并发负载测试、测试场景搭建、运行、监控及结果分析 优点:支持多协议、自带强大的图表功能、可根据需求合并需要的图表 缺点:收费
五、性能指标
通常进行基准测试的时候,在结果中会有很多需要值得关注的目标,下面列举一些比较重要的。
1、QPS/TPS(衡量吞吐量)
QPS是我们的每秒查询数量,TPS是每秒的事务数量。通常我们进行基准测试往往会定一个目标,比如支撑1000QPS的请求量来完成我们的目标,或者测试出我们这个系统极限的QPS是多少,同样的QPS也不是越大越好,也需要结合我们的响应时间,如果我们一味的追求QPS忽略了响应时间那么用户的体验也是极差的。
2、TP99/TP95
有很多认为响应时间应该看平均时间,如果写要求比较低的系统的确是可以看平均时间,这样就会导致很多用户响应的速度很慢,但是我们在监控指标上体现不出来,所以就有了百分位指标这样的概念,TP99的意思就是,取排名排到第99百分位的响应时间,即排除了一些异常的情况(剩余的那1%),又保证了大多数用户的响应时间。(平均响应时间、最小响应时间、最大响应时间、时间百分比等,其中时间百分比参考意义较大,如前95%的请求的最大响应时间。)
3、CPU(并发量)
当我们有很多CPU密集型应用的时候,可以多多关注CPU的情况,从而进行针对性的调优
4、GC
如果是Java的应用,GC问题绝对不会缺席,尤其是在我们基准测试中,往往如果在测试中出现了大量的GC,说不定是代码写得有问题,有时候可以通过代码进行优化,或者说也可以更换GC收集器。
5、io
当我们传输的数据比较多的时候,比如传输文件,或者一些大的数据结构,这个时候就需要关注I/O相关的问题,来进行针对的调优。
6、 点击数
点击数是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。
点击数不是通常一般人认为的访问一个页面就是1次点击数,点击数是该页面包含的元素(如:图片、链接、框架等)向Web服务器发出的请求数数量。
通常我们也用每秒点击次数(Hits per Second)指标来衡量Web服务器的处理能力。
7、 资源利用率
是指系统各种资源的使用情况,一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
通常,没有特殊需求的话:
建议CPU使用率不高于80%(±5);
内存使用率不高于80%;
磁盘读写时间比不高于90%。
8、 错误率
错误率指系统在负载情况下,失败交易的概率。错误率=(失败交易数/交易总数)*100%。
不同系统对错误率要求不同,但一般不超过千分之五;
稳定性较好的系统,其错误率应该由超时引起,即为超时率。
六、可对比
可对比同样是基准测试的重要点,通常有下面的几个点:
使用不同的测试工具做对比
使用不同的测试数据做对比
使用不同的测试环境做对比
建立长期的基准测试,进行不同时间的基准测试对比。
通常基准测试就是要随时进行测试因子变量的变更,我们才能真正的得到最优的测试结果。
参考:聊聊基准测试 - 云+社区 - 腾讯云 (tencent.com)
https://cloud.tencent.com/developer/article/2377575