最近又在搞性能测试了,相较于之前的写脚本出数据就完事,这次深入的思考了一下测试出来的指标,到底有什么意义???
绞尽脑汁思考了好几天,终于有了点思路,写出来与大家分享,有不对的地方也希望大家能指出;
此处我们只探讨“单交易并发测试”这一个测试场景,本次单交易并发测试共测试了7个接口,我们下面拿一个接口为例来说:
1、首先,通过jmeter阶梯加压,我们发现jmeter线程数到50的时候,响应时间在可接受范围,TPS已经不再明显增加;
2、于是jmeter线程数给到50,持续加压5分钟,得到如下结果:
响应时间OK,TPS达到405.4/sec也OK(OK与否要与前期制定的性能方案做对比)
此时对比了TPS以后,达标了,就想着要测试下一个接口啦;但是:
一同事认为只关注TPS,达标了就可以了;
另一同事认为从用户使用角度,我们还要关注用户并发数,这个并发数反映了用户给系统的压力;现在我们得到了最大TPS,但是并发数还没有加到最大啊,应该继续加压找到最大的并发数!
这个时候感觉同事的话有道理又没道理,于是拿出了那个经典的图思考了半天(没错,就是下面这张图):
随着并发压力的增加,前期响应时间较小,TPS持续上升,达到第一个拐点(此处认为就是我们上面测试的50),TPS达到了最大;
再持续加压,响应时间会增加,TPS也不会上升,一直到第二个拐点(感觉上像是同事想要压到的最大并发点),响应时间达到能接受的最大,TPS也能维持不下降;
思考了半天,觉得也应该继续压,找到系统的这个瓶颈,但是没考虑弄清楚压出来的数据有什么用,但是不管了,先压一版数据看看;
3、于是jmeter线程数给到了400,持续加压了5分钟,得到数据如下:
TPS到了498.0/sec,上升了一些
响应时间,看95%响应时间已经超了3S
4、头脑风暴
得到2组数据以后,我们看TPS都是达到要求的,但是这个50和400,怎么理解呢?
用户并发数50的时候系统性能最优,用户并发数400的时候系统性能达到瓶颈???
NO!!!TPS都能到400多,说明每秒可以处理400个请求,怎么可能用户并发数到400,系统就极限了呢!
--------------------------纠结中,网上搜索资料。。。
网上搜索了一些资料后,发现陷入了一个误区,即:我思考时,默认了这个jmeter线程数就是模拟了用户并发数,但是!不是这样的!!!
我们回去看,线程数为50时得到的结果,会发现其中有一个样本数121821,之前都忽略了这个值,现在我们分析:
1、线程数给了50,这里是工具给我们起了50个线程;
2、如果并发数是50,1S发送50个请求,那么5分钟时间,应该是发送了50*60*5=15000个请求;
3、但是跑了5分钟以后,我们发现样本为121821,远远超过了15000,就是在5分钟的时间内,给服务器发送了121821个请求;
4、那么121821/(5*60)=406,就是1S中发送了406个请求啊,就是用户并发数406啊,根本就不是50~
同理,149810/(5*60)=499
5、然后,我们发现:406 499 ,这不就是TPS吗!所以,我们关注用户并发数,到最后也就是这个TPS啊==
所以,我们是不是可以理解:
用户并发数406的时候,系统的性能是最优的,用户得到的响应也很快??
用户并发数499的时候,系统的性能达到了瓶颈,达到了用户能接受的响应时间极限??
嗯,应该是这样吧。。。