本文探讨了JMeter测试报告中吞吐量误差较大的问题，通过实例分析发现，JMeter在计算吞吐量时包含了本机处理时间，这可能导致实际吞吐量与预期存在较大差距。作者建议在压测过程中注意线程中的额外处理，如正则匹配，可能会影响吞吐量，并提出了利用微基准测试修正压测结果的方法。
JMeter吞吐量可能是个假数据，因为它计算的是本机而不是服务端。
我自己并不用JMeter进行压测，故事的缘起是因为看到了同事适用JMeter进行测试的测试报告，偶然间发现一个问题，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，误差已经很大了。
到底是什么原因导致误差如此之大呢，经过研究同事的压测过程，发现了在第三个案例中，他使用了较多的正则匹配来校验响应返回值。那么是不是JMeter在处理返回值消耗的时间较多导致了计算吞吐量误差的呢？不由让我想起之前的文章：利用微基准测试修正压测结果、
最低0.47元/天 解锁文章
扫一扫
1125
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
