你真的了JMeter解聚合报告么？

1.背景

你们在使用JMeter进行性能测试时，聚合报告(Aggregate Report)能够说是必用的监听器，可是你真的了解聚合报告么？

2.目的

本次笔者跟你们聊聊聚合报告(Aggregate Report)经常使用误区。

3.常见误区

说明：本次笔者采用的JMeter版本为5.1.1

• 误区一：90%、95%、99百分位的理解

常常有的同窗理解成平均90%、95%、99%请求的交易耗时，包括一些作了好久的老测人员试居然也是这么理解的（其实笔者最开始也是这么理解的），出现这个问题根本缘由是对百分位的概念理解错误（换句话说：你数学是体育老师教的吧！），那么正确该怎么理解呢？

咱们来看一张聚合报告图：

正解：90%百分位值为230ms，在发送100笔请求过程当中，聚合报告会实时给请求耗时进行由小到大行排序，排序后的第90个请求耗时为230ms，也就是说前90笔请求中耗时最长的是230ms（其他90%百分位，95%百分位道理相似就不占篇赘述了），聚合报告平均值要与百分位值结合来看。

说明：90%、95%、99%值是支持自定义在jmeter.properties修改：

• 误区二：把吞吐量值当TPS值

常常有的同窗直接把聚合报告中的吞吐量看成TPS来看（网上还有一种说法是把请求放在事务控制器里，吞吐量就能够当作TPS，经笔者验证并不能够）,这种作法是至关不严谨的。那么聚合报告中的吞吐量什么状况下能够当作TPS?

老规矩仍是用实际操做来验证：

没错，仍是上面聚合报告的图，笔者把100.jtl文件中的请求所有改为false,再来看下聚合报告结果：

而后再用聚合报告打开100.jtl结果文件，聚合报告各项数据没有任何改变（笔者就不放图了，否则就一张图用了3遍），笔者这种作法是比较极端的（或者能够说笔者把现象放大了），此时再把吞吐量当作TPS就出事了。。。。请求全失败了，TPS应该是0吧？？？？？

给你们举个栗子，你们都看过赵本山大叔的《钟点工》小品，里面有个经典的问题：把大象关进冰箱须要几步？相信你们都知道答案。咱们换种思惟：假如咱们把这个操做当作一个事务，若是找不到大象，或者没有冰箱，这个事务都是没法完成的，也就是说这个事务最终会失败(事务只有两种状态要么成功要么失败)。

那么何时吞吐量能够成TPS,从严格意义来说就是交易成功率为100%；还有一种状况是：交易失败率在你能够接受的范围内（对当前测试总体结果影响不大，到了能够忽略的程度）。

咱们再来验证下网上说的方法吧：把请求放在事务控制器里

脚本结构图：

有的同窗能够能会问：事务控制器为啥不放多个请求，其实从本质上看是没这个必要的，放多个请求也不影响最终结果。

笔者仍是用以前的操做把100_2.jtl中的请求所有改为false,再来看下聚合报告结果：

聚合报告结果图（为何会整体样本会是200，笔者以为问题出在逆向解析过程当中会把JTL结果文件中全部的样本解析出来）：

吞吐量的值仍是没有变，此时吞吐量值预期结果应该是零，进而证实网上的所谓的套路不靠谱（感受网上说的增长事务控制器的，目的更偏向与如何把多个请求组装成一个事务，这也是事务控制的做用）。

4.JMeter聚合报告源码优化

针对以上问题，笔者查看了聚合报告底层源码，总结下：聚合报告是无状态的（状态是样本的状态），只负责统计数据（就是个计数器），统计时只认Sampler的Label，笔者我的感受源生的聚合报告，不是十分合适OLTP。

笔者优化了：统计计算公式，支持GUI页面控制（默认勾选统计tps，若是不勾选则仍是统计吞吐量）

再看下100.jtl结果文件所有false效果：

笔者手动改下100.jtl改为只失败1笔，执行结果以下：