我相信你同意:有很多方法可以收集和解释JMeter结果,你会感到迷茫。
嗯,看完这篇文章后,您将了解收集和分析结果的12种不同方法!
我们将探索每种可能的方式来获得富有洞察力的指标,包括图形,图表,表格,HTML报告等。JMeter是一个如此复杂的工具,有很多惊人的可能性,很难知道该怎么做。
关于如何分析JMeter结果的最终指南将启动您的JMeter知识。
先决条件
安装
本教程假设您已经安装了以下软件:
- Java 8,
- JMeter 3.3或以上。
在整个指南中,使用以下Sample JMX。这个JMX 基于Docker Image中捆绑的Java JPetstore 测试我们的演示应用程序。
了解JMeter指标
JMeter Metrics在以下部分中被广泛使用,因此如果您对其定义感到满意,则会更好:
- 经过的时间:测量从发送请求之前到刚收到响应的最后一个块之后的经过时间,
- 延迟:测量从发送请求之前到收到响应的第一个块之后的延迟,
- 连接时间:测量建立连接所需的时间,包括SSL握手,
- 中位数:将样本分成两等份的数字,
- 90%线(90%百分位数):经过的时间低于90%的样本下降,
- 标准偏差:测量数据集的可变性。这是一项标准统计指标,
-
线程名称:派生自线程组名称和组内的线程。名称的格式为groupName +“”+ groupIndex +“ - ”+ threadIndex其中:
- groupName:线程组元素的名称,
- groupIndex:测试计划中的线程组编号,从1开始,
- threadIndex:线程组中线程的编号,从1开始。
-
吞吐量:按请求/时间单位计算。时间从第一个样品的开始到最后一个样品的结束计算。公式为:吞吐量=(请求数)/(总时间)。
解释JMeter指标
你怎么知道一个指标是令人满意还是糟糕?以下是一些解释:
- 经过时间/连接时间/延迟:应尽可能低,理想情况下小于1秒。亚马逊发现每100毫秒的销售成本为1%,这意味着损失了数百万美元,
- 中位数:应接近平均经过的响应时间,
- XX%线:应该尽可能低。当它低于平均经过时间时,它表示最后的XX%请求的响应时间比较低的响应时间要快得多,
- 标准差:应该很低。高偏差表示响应时间的差异,这意味着响应时间峰值。
看,这很简单!大多数数字应该尽可能低。但是,根据具体情况,您的老板可能会在给定负载下为您提供预期的响应时间。使用它们来计算每个请求的Apdex:
Apdex(应用程序性能指数)是由公司联盟开发的开放标准。它定义了一种报告和比较计算中软件应用程序性能的标准方法。
JMeter HeadLess测试
要在无头(非GUI)模式下运行JMeter,这意味着没有任何UI,要运行负载测试,请使用以下命令:
jmeter -n -t scenario.jmx -l jmeter.jtl
命令行具有以下参数:
- -n:在非GUI模式下运行,
- -t:指定要运行的源.jmx脚本的路径,
- -l:指定包含原始结果的JTL文件的路径。
请参阅我们的博客文章如何优化JMeter进行大规模测试,以了解为什么在非GUI模式下运行至关重要。
运行演示应用程序
要在您自己的计算机上运行演示应用程序,您需要:
要运行JPetstore演示应用程序,只需执行命令行即可docker run -d -p 8080:8080 jloisel/jpetstore6
。
打开浏览器,然后导航到http://localhost:8080/actions/Catalog.action
。它应该显示JPetstore首页。
线程组配置
将运行以下测试:
- 20个并发线程组,
- 120秒加速持续时间,
- 120秒峰值测试持续时间。
测试将运行总共4分钟,其中20个并发用户峰值负载。
UI听众
JMeter有许多UI Listener,可用于直接在JMeter UI中查看结果:
- 以树形式查看结果:查看结果树显示所有样本响应的树,允许您查看任何样本的响应。
- 图形结果:图形结果监听器生成一个简单的图形,绘制所有采样时间,
- 聚合报告:聚合报告为测试中的每个不同命名的请求创建一个表行,
- 在表中查看结果:此可视化工具为每个样本结果创建一行。与查看结果树一样,此可视化工具使用大量内存,
- 聚合图:聚合图与聚合报告类似。主要区别在于聚合图提供了一种生成条形图并将图形保存为PNG文件的简便方法,
- 生成摘要结果:此测试元素可以放在测试计划中的任何位置。生成到目前为止测试运行的摘要到日志文件和/或标准输出。显示运行和差异总计。
一些侦听器已被省略:这些侦听器仅用于调试目的。这些侦听器有助于诊断脚本问题,但无意提供性能指标,如下所示:
- 比较断言Visualizer:比较断言Visualizer显示任何Compare Assertion元素的结果,
- 或断言结果:断言结果可视化器显示每个样本的标签。
作为一般经验法则,请避免使用UI Listeners。它们消耗大量内存。它们不适合实际负载测试。有些甚至可能只运行几个并发线程组而触发和Out Of Memory错误。
放置听众
根据结果监听器的放置位置,它会收集不同的指标。JMeter结果侦听器从同一级别或更低级别的所有元素收集结果。因此,建议将监听器置于测试计划级别以收集所有线程组结果。
查看结果树
查看结果树本质上是一个调试发送的请求和收到的响应的工具。查看脚本是否正确运行很有用。但是,当许多并发用户正在运行时,它不适合查看结果。它会很快耗尽内存,因为它会将所有结果保存在主内存中。
单击每个请求时可以使用某些指标,如下所示:
Thread Name: JPetstore 1-1
Sample Start: 2017-10-06 10:42:09 CEST
Load time: 30
Connect Time: 0
Latency: 29
Size in bytes: 1530
Sent bytes:582
Headers size in bytes: 196
Body size in bytes: 1334
Sample Count: 1
Error Count: 0
Data type ("text"|"bin"|""): text
Response code: 200
Response message: OK
我建议使用这个监听器:
- 在将测试扩展到大量并发用户之前调试脚本,
- 通过为一次迭代运行单个线程组来定义基准性能指标,
- 和/或使用收到的响应来修复/设计后处理器以提取动态参数。
聚合图
聚合图是一个UI Listener,它为每个请求和事务控制器提供了一些有用的测试范围指标。它还包括一个条形图,可以通过许多不同的设置进行调整以满足您的需求。我必须说,有太多的设置,更糟糕的是,这些设置都没有保存在JMX中。关闭JMeter时松开它们。
虽然,我必须承认能够将图表导出为PNG并将表格导出为CSV以便将来在自定义设计的报告中使用,这非常好。
度量标准是测试范围的,这意味着您可以获得整个测试请求的平均响应时间。可用的指标是:
- 标签:请求的名称,
- #Samples:执行总数,
- 平均值:平均经过时间,以毫秒为单位,
- 中位数:中位数是将数据样本的较高一半,人口或概率分布与下半部分隔开的值。对于数据集,它可以被认为是“中间”值,
- 90%线:90%百分位,百分位数(或百分位数)是统计中使用的一种度量,表示一组观察中给定百分比的观察值下降的值,
- 95%线:95%百分位,
- 99%线:99%百分位,
- 最小值:最小经过时间,
- 最大:经过的最长时间,
- 错误%:错误百分比(错误/(错误+样本)* 100),
- 吞吐量:每秒样本数,
- 和KB /秒:网络吞吐量,单位为千片/秒。
与任何其他UI Listener一样,我不建议将其用于实际负载测试。
汇总报告
聚合报告与聚合图非常相似,仅包含度量表。在运行无头负载测试(没有启动UI)时可以使用此侦听器,因为统计信息可以保存在CSV文件中供以后使用。它包含与聚合图完全相同的指标。然后,可以使用这些度量来使用Word编写报告。
生成摘要结果
JMeter摘要结果监听器在JMeter控制台的负载测试期间输出结果,如下所示。
它每隔几秒就会显示一些常规指标:
Generate Summary Results + 5 in 00:00:07 = 0.8/s Avg: 159 Min: 29 Max: 238 Err: 1 (20.00%) Active: 1 Started: 1 Finished: 0
Generate Summary Results + 7 in 00:00:22 = 0.3/s Avg: 163 Min: 54 Max: 239 Err: 0 (0.00%) Active: 0 Started: 1 Finished: 1
Generate Summary Results = 12 in 00:00:28 = 0.4/s Avg: 161 Min: 29 Max: 239 Err: 1 (8.33%) Generate Summary Results + 17 in 00:00:25 = 0.7/s Avg: 185 Min: 28 Max: 524 Err: 3 (17.65%) Active: 3 Started: 3 Finished: