今天文章干货满满,松勤软件测试带大家一起来了解一下性能测试里的指标有哪些?
 
01
性能指标
 
 

 

TPS:启动一个压测任务,我们最开始看到的监控数据是性能指标。如下tps曲线图,绘制出来的是不同并发下tps数据,这里主要看的就是增加并发后tps能否平缓增加,如按一定比例上升,服务处理能力还未到瓶颈,如未到性能指标,可继续增压。如果是增加并发量tps不增或者下降,可能服务已经过载。
响应时间:同时结合一起看的还有响应时间,如果增加并发后,tps增加,响应时间不增加,服务处理能力还未到瓶颈,如果增加并发,tps不增加或者增加缓慢,这种情况响应时间也会增加,因为服务的处理能力一定到最大了,依据并发和响应时间成正比的关系,并发增加的同时响应时间会增加。
日常情况下看TP90,TP99,TP999的值。平均响应时间是个平均值,在值不均匀稳定的情况下,很容易把结果值拉低或者拉高。
 

 
错误率:除了上述指标我们还需要看请求通过率,在压测期间,如果失败的请求数较多,确认压测脚本和参数无误后,再看压测平台日志,是否有异常或错误报出,还有服务的error日志,依次确认失败原因,直到错误率在一个合理的范围内。
 

 
02
服务指标
 
 
 
 
启动压测任务后,我们同时需要观察服务的资源情况,良好的情况下,服务压力增加,性能指标增加,服务资源消耗增加,但是有时候可能并非如此,下面介绍服务侧应该看哪些指标。
 
(1)应用服务器资源,主要监控cpu、内存、磁盘、网络带宽。如果接口有复杂的算法、或者请求到一定的量、机器数量较少时,cpu利用率可能会比较高;如果接口返回值较大,可能网络带宽会有一定的消耗;如果读写操作比较多,如数据库频繁插入、更新,磁盘util%一般会增大,压测前对业务逻辑有个了解,监控才能有侧重点。
 
(2)应用服务,大并发量的请求时,时不时的刷一下error日志,看看是否有异常,大量的插库是否有主键冲突等问题。
 
(3)应用服务jvm虚拟机,启动java应用时,会确定服务的初始堆内存、最大最内存、最小堆内存大小,以及内存回收的方式。目前平台都会设置默认值,大部分情况下使用默认配置即可,不过如果某业务对吞吐量或者平响有较高要求,可能还需要调整新生代和老年代的大小比例,来保证GC回收造成的服务停止时间在指定的数值范围内。
 
如下图堆内存在一定时间回收后降到初始大小,基本可以确定无内存泄漏问题;如果曲线整体呈递增趋势,那可能是内存对象回收不彻底,有内存泄漏的可能,确认该种问题是否存在可以调小堆内存的大小,对接口发请求,同时观察回收曲线。还有关注下新生代、老年代回收次数是否频繁,FGC每次回收时间是否较长(超过1s)。
 

 
(4)数据库服务除了上述资源指标,还要关注查tps,写tps,慢查询的统计,是否有主从延时的情况等。如有时候服务端统计到的tps只有1000,数据库统计到的tps倍数很大,可能存在一次请求多次操作数据库、操作数据库太频繁的问题。慢查询的话可能是没建索引,或者是建了索引,因索引不合理未走索引,还有可能是数据库数据量太大,索引也很大,影响了性能。
 
(5)正式链路中可能还会有jen层,发起压测任务后,请运维同学协助看jen层的耗时、keep-alive链接数、带宽消耗等信息。
 
03
缓存中间件
 
 
 
 
为了提升服务的性能,大部分架构都会用到缓存中间件,项目中一般使用r2m,因r2m本身性能较好,大量请求下观察r2m各分片负载是否均匀,是否存在大key问题、tps突增突降、慢日志等。
 
还有写操作请求量较大时,r2m内存被使用量到一定的量(80%左右),可能会启动自动扩容策略,在扩容期间请求会受影响,这种也会对性能有一定的影响。
 
消息队列的还需要关注消息数是否堆积、消费侧的消费能力,这种情况下tps可能不能按服务的请求量来算,而应该用消费的量来算。
 
04
压力机指标
 
 
 
 
就公司目前的压测平台来说,极少会发生压力机过载的情况,不过因为压测任务参数配置不合适,可能会出现该种问题。启动任务后,观察一下压力机负载情况,还有压力机的日志。
(1)发压配置
以forcbot为例,压力机线程总数=单机压力机最大线程数*单机最大进程数,压力机的负载主要是任务的单机线程数和最大进程数的大小来影响的,如果配置较小压力不够,压力机负载低,同时tps可能也上不去,配置较大压力机负载过高,成为瓶颈。在压测期间观察压力机的负载,让该值保持在50%左右,如果负载较高,就调小单机线程或者进程,小则反之。
 

 
(2)压力机监控
如下是压力机的cpu使用率,在整个压测期间最高15%,大部分是6%左右,可以排除压力机瓶颈。
 
 

 
05
监控告警
 
 
 
除了常见的监控指标,还有一个不能忽略的就是看监控告警,压测期间服务告警不要关闭,以防出现问题不能发现。