JMeter吞吐量偏差分析

2022年01月15日 阅读数:1
这篇文章主要向大家介绍JMeter吞吐量偏差分析,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

JMeter吞吐量多是个假数据,包含了本机处理时间。并发

首先我自己并不用JMeter进行压测,故事的缘起是由于看到了同事适用JMeter进行测试的测试报告,偶然间发现一个问题,JMeter报告中的吞吐量偏差较大。结果如图:ide

JMeter吞吐量偏差分析_响应时间

按照经典理论模型计算吞吐量TPS或者QPS应该是等于并发线程数除以平均响应时间:性能

tps =Thread / AVG(t)测试

或者 tps = COUNT(request) / T线程

你们看第一个案例:平均响应时间593ms,100并发,计算获得的吞吐量为:168.63,JMeter给出的吞吐量为166.4,偏差几乎能够忽略。再看第三个案例:100并发,平均响应时间791ms,计算获得的吞吐量为126.422,JMeter给出的吞吐量为92.3,偏差已经很大了。it

究竟是什么缘由致使偏差如此之大呢,通过研究同事的压测过程,发现了在第三个案例中,他使用了较多的正则匹配来校验响应返回值。那么是否是JMeter在处理返回值消耗的时间较多致使了计算吞吐量偏差的呢?不禁让我想起以前的文章:​​利用微基准测试修正压测结果​​​、​​性能测试如何减小本机偏差​​。class

那么咱们经过一个实验验证一下:首先写一个脚本,我用了单线程的脚本,请求10次看结果:变量

JMeter吞吐量偏差分析_性能测试_02

看结果,平均响应时间207ms,一个并发,计算获得的结果为4.83,JMeter给出的结果4.8,符合预期。配置

而后我用一个Groovy后置处理器,让线程休眠500ms,而后仍是单线程并发,请求10次的结果:循环

JMeter吞吐量偏差分析_压测_03

看结果,平均响应时间193ms,跟第一次结果差很少,JMeter给出的吞吐量值为1.5,偏差巨大。

那么1.5的吞吐量是怎么来的呢?咱们给193ms加上咱们的等待500ms(这里是应该加上500 * 9 / 10),计算结果为1.54,跟JMeter给出的1.5符合,基本能够判定JMeter在计算吞吐量时候,把本机处理的过程也是计算在内的。

若是JMeter在整个请求过程当中平均响应时间是正常统计请求发出到接收到响应的时间,可是吞吐量缺失用本机的整个线程一次循环的时间做为吞吐量计算的依据。

若是你在线程中作了别的事情,好比正则提取,参数校验,变量赋值等等都会致使吞吐量会变小。而一旦本机处理时间增长,那么压测过程当中给服务端的实际压力也是比配置的要小,若是本机性能消耗过大或者某些地方发生等待,那么获得的吞吐量就能够当作一个假数据处理了。

这里我给出一个方案​​利用微基准测试修正压测结果​​​、​​性能测试如何减小本机偏差​​。

若是发现偏差较大,必定要进行结果修正,避免假数据。