『动善时』JMeter基础 — 54、JMeter聚合报告详解

时间:2023-03-08 16:36:36

提示:聚合报告组件的使用和察看结果树组件的使用方式相同。本篇文章主要是详细的介绍一下聚合报告组件内容,不做示例演示。

1、聚合报告介绍

在使用JMeter进行性能测试时,聚合报告(Aggregate Report)可以说是必用的监听器。

(1)聚合报告的生成方式

聚合报告有2中生成方式:

  1. 在已有.jtl文件的情况下,直接选择加载文件即可生成聚合报告。
  2. 在运行JMeter的过程中,动态生成聚合报告。

提示:我们一直使用GUI模式操作JMeter,所以看到的聚合报告组件中的内容,是第二种生成方式。等之后我们介绍非GUI模式操作JMeter时,会讲解第一种方式生成的聚合报告。

(2)聚合报告的数据来源

聚合报告中统计的数据来源,其实都是从统计的SampleResult中收集的数据。

需要特别注意的是

  1. 聚合报告中的每一行,代表一个请求。注意:同名的请求会只显示一个,把结果合并。
  2. 聚合报告中的每一列信息,是由SamplingStatCalculator类的不同方法实现统计的,相同名称的请求会共用同一个SamplingStatCalculator
  3. 不管是JMeter实时生成聚合报告,还是根据已经存在.jtl结果文件生成的聚合报告,最终的底层都是调用StatGraphVisualizer类的add(sampleResult)方法来生成表格的一行数据,传递的参数为每个请求的请求结果(sampleResult)信息。

    add方法的调用时机:

    1)根据.jtl文件生成报告时,每解析一行数据就调用一次add方法。

    2)实时运行生成聚合报告,每请求一次,就调用一次add方法。

提示:

  1. 注意:使用聚合报告时,测试计划中不要用相同的的请求取样器名称。
  2. 观察聚合报告的结果发现,聚合报告是累加的,即每次运行的结果统计都是基于前一次运行的结果进行统计,包括发起的请求样本数等都是叠加的。

2、聚合报告界面详解

添加聚合报告组件方式:选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告

界面内容如下图所示:

『动善时』JMeter基础 — 54、JMeter聚合报告详解

聚合报告界面说明:

  • 名称聚合报告组件的自定义名称,见名知意最好。
  • 注释:即添加一些备注信息,对该聚合报告组件的简短说明,以便后期回顾时查看。

(1)将所有数据写入一个文件

在JMeter中,我们可以将脚本测试中每个用户的访问内容,都存储到一个文件中。

需要操作聚合报告组件中的如下位置:

『动善时』JMeter基础 — 54、JMeter聚合报告详解

说明:

  • 文件名:输入一个文件的完整路径,后缀可以为.csv.html等。文件若不存在,则创建该文件;若已存在该文件,运行结果选择覆盖原有文件即可。
  • 显示日志内容:

    1)仅日志错误:仅保存错误的日志信息到文件中。

    2)仅成功日志:仅保存正常响应的日志信息到文件中。
  • 配置(configure):配置测试结果文件中需要记录的内容,可以依据自己需求来选择。

    如下图所示:

    『动善时』JMeter基础 — 54、JMeter聚合报告详解

提示:我们可以点击“浏览”按钮,选择已存储的聚合报告文件,来查看之前脚本的请求结果。

(2)聚合报告列表项介绍

  1. Label:请求的名称,就是脚本中Sampler的名称。
  2. # Samples(样本):总共发给服务器的请求数量,如果模拟10个用户,每个用户迭代10次,那么总的请求数为:10*10 =100次。
  3. Average(平均值):默认情况下是单个Request的平均响应时间,当使用了Transaction Controller(事务控制器) 时,也可以用Transaction的时间,来显示平均响应时间 ,单位是毫秒。
  4. Median(中位数):50%用户的响应时间小于该值。
  5. 90% Line(90% 百分位):90%用户的响应时间小于该值。
  6. 95% Line(95% 百分位):95%用户的响应时间小于该值。
  7. 99% Line(99% 百分位):99%用户的响应时间小于该值。
  8. Min(最小值):最小的响应时间。
  9. Maximum(最大值):最大的响应时间。
  10. Error%(异常%):错误率=错误请求的数量/请求的总数。
  11. Throughput(吞吐量):默认情况下表示每秒完成的请求数(Request per Second)。
  12. Received KB/sec (接收数据):每秒从服务器端接收到的数据量。
  13. Sent KB/sec(发送):每秒发送到服务器端的数据量。

(3)保存聚合报告报表

  1. 在标签中包含组名称?:需要就勾选,不需要则取消勾选。
  2. 保存表格数据:就是保存聚合报告页面中显示的表格内容,而不是用户的请求日志信息。
  3. 保存表格标题:需要就勾选。

3、聚合报告中信息点说明

(1)百分位数的说明

1、科普90% Line参数正确的含义

在这里我觉得有必要说一下对 90%Line 的理解:

很多人都理解为:90%用户的平均响应时间。我之前也一直这样认为,但是后来才发现我错了。

那看看JMeter 官网是怎么说的?

90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.

意思是:有 90% 的样本不超过这个时间, 剩下的样品至少只要等于或超过这个时间。

换句话说,就表示有90%的请求耗时,都在这个时间之内。

2、这里涉及到一个数学中的概念:百分位数

百分位数:统计学术语,如果将一组数据从大到小排序,并计算相应的累计百分位,则某一百分位所对应数据的值,就称为这一百分位的百分位数。可表示为:一组n个观测值按数值大小排列,处于p%位置的值称第p百分位数。

百分位通常用第几百分位来表示,如以身高为例,身高分布的第5百分位,表示有5%的人的身高小于此测量值,95%的身高大于此测量值。

3、再举个例子:

有10个数:1、2、3、4、5、6、7、8、9、10,按由小到大将其排列。

求它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line就是9 。

4、那么百分位数用在性能测试中有什么意义呢?

它可以使用我们的分析结果更准确!

因为在评估一次测试的结果时,仅仅有平均响应时间是不够的。假如在一次测试中,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒。你会不会想到最小和最大响应时间,这样如此大的偏差,是否会导致平均值本身并不可信?

如果我们把每个请求的响应时间用Excel统计出来,会发现那个最大值的出现几率,只不过是千分之一甚至万分之一,剩下99%的用户请求的响应时间,都是在性能需求所定义的范围之内的。所以为了更准确的衡量整体请求的耗时情况,除了平均响应时间之外,还要有90%Line95%Line99%Line来辅助统计。

总结一下,聚合报告中的百分位数的含意:

  • Median:中位数,50%用户的响应时间在小于该值,注意它与Average平均响应时间的区别。
  • 90% Line:90%用户的响应时间小于该值。
  • 95% Line:95%用户的响应时间小于该值。
  • 99% Line:99%用户的响应时间小于该值。

(2)吞吐量说明

吞吐量(QPS):默认情况下表示每秒完成的请求数。

误区:把吞吐量值当服务器每秒处理的事务数的值(TPS)。

经常有的同学直接把聚合报告中的吞吐量当作TPS来看,这种做法是相当不严谨的。

那么聚合报告中的吞吐量什么情况下可以看成TPS?

从严格意义来讲就是交易成功率为100%(一个完整的事务)。

还有一种情况是,交易失败率在你可以接受的范围内,也就是对当前测试整体结果影响不大,到了可以忽略的程度。

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

那么这些步骤就不能算事务的完成,所以事务完成数和请求完成数之间还是有区别的。

参考: