JMETER结果分析
我相信你同意:有很多方法可以收集和解释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: 0
Generate Summary Results + 32 in 00:00:30 = 1.1/s Avg: 160 Min: 28 Max: 239 Err: 2 (6.25%) Active: 2 Started: 5 Finished: 3
Generate Summary Results = 49 in 00:00:55 = 0.9/s Avg: 169 Min: 28 Max: 524 Err: 5 (10.20%)
Generate Summary Results + 29 in 00:00:30 = 1.0/s Avg: 164 Min: 28 Max: 246 Err: 3 (10.34%) Active: 3 Started: 8 Finished: 5
Generate Summary Results = 78 in 00:01:25 = 0.9/s Avg: 167 Min: 28 Max: 524 Err: 8 (10.26%)
Generate Summary Results + 31 in 00:00:30 = 1.0/s Avg: 165 Min: 28 Max: 242 Err: 2 (6.45%) Active: 2 Started: 10 Finished: 8
Generate Summary Results = 109 in 00:01:55 = 0.9/s Avg: 166 Min: 28 Max: 524 Err: 10 (9.17%)
Generate Summary Results + 4 in 00:00:05 = 0.8/s Avg: 168 Min: 138 Max: 181 Err: 0 (0.00%) Active: 0 Started: 10 Finished: 10
Generate Summary Results = 113 in 00:02:00 = 0.9/s Avg: 166 Min: 28 Max: 524 Err: 10 (8.85%)
在无头模式下运行JMeter时,默认情况下已输出这些日志行。在Jenkins上运行JMeter时,JMeter Jenkins插件能够解析这些行并输出图形。
图表结果
JMeter图表结果显示常用指标的线图和数字数字:
- 样品数量:正在处理的样品数量,
- 最新样本:最新经过时间,以毫秒为单位,
- 平均经历时间:以毫秒为单位,
- 标准差:以毫秒为单位,
- 和吞吐量:以KB /秒为单位。
这个结果听众不值得。图表几乎无法读取。并且,如JMeter文档中所述:
在负载测试期间不得使用图形结果,因为它消耗了大量资源(内存和CPU)。仅用于功能测试或测试计划调试和验证期间。
摘要
总而言之,大多数UI监听器非常适合调试/测试目的。不要期望达到高负荷(> = 500个用户),谨慎使用它们。这些侦听器设计用于在JMeter UI中运行负载测试时快速获取指标,以实现轻负载。(<= 50个并发用户)
即使是中等负载(100-500个并发用户)也可以使用它们,但不要期望使用JMeter UI运行分布式JMeter测试。这不是目的。记住JMeter默认配置512MB堆内存,相当低。虽然你可以增加JMeter分配的内存,但它会感觉不会再漂浮在船上了。
现在我们已经测试了JMeter中可用的大多数UI监听器,问题显然是:在运行实际负载测试时我们可以使用哪些监听器?
无头听众
无头JMeter监听器(或非UI)专门设计用于在命令行运行JMeter时工作。这些侦听器是在运行实际负载测试时使用的侦听器,因为它们使用的内存远少于UI侦听器。怎么样?这些监听器不会将结果保留在内存中,它们主要负责将结果卸载到另一个介质。
现有的非GUI JMeter监听器是:
- 简单数据写入器:可以将监听器配置为将不同的项目保存到结果日志文件(JTL),
- 后端监听器:后端监听器是一个异步监听器,使您可以插入BackendListenerClient的自定义实现。默认情况下,提供Graphite实现。
简单的数据编写者
这是JMeter中最有用的监听器。它根据外部文件中的配置保存性能指标:JTL文件。JMeter JTL文件是分析结果的最佳方式,但有一个缺点:您需要另一个工具来执行数据挖掘。
目前有两种类型的JTL文件:
- CSV(默认,有或没有标题),
- 和XML。
XML文件可以包含更多类型的信息,但要大得多。因此,建议坚持使用CSV格式。生成的jmeter.jtl包含如下数据:
timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,Latency,IdleTime,Connect
1507280285885,221,Home page,,"Number of samples in transaction : 1, number of failing samples : 1",JPetstore 1-1,,false,,59592,10154,1,1,50,1,23
1507280286687,29,signinForm,200,OK,JPetstore 1-1,text,true,,1531,582,1,1,29,0,0
1507280286108,29,Login page,200,"Number of samples in transaction : 1, number of failing samples : 0",JPetstore 1-1,,true,,1531,582,1,1,29,580,0
1507280286819,147,viewCatalog,200,OK,JPetstore 1-1,text,true,,3460,11027,1,1,27,0,0
1507280287967,233,signinAccount,200,OK,JPetstore 1-1,text,true,,3719,13270,1,1,55,0,27
1507280286717,380,Signin,200,"Number of samples in transaction : 2, number of failing samples : 0",JPetstore 1-1,,true,,7179,24297,1,1,82,1104,27
1507280292035,162,viewCategory,200,OK,JPetstore 1-1,text,true,,2600,6502,1,1,56,0,26
1507280288201,162,ViewCategory,200,"Number of samples in transaction : 1, number of failing samples : 0",JPetstore 1-1,,true,,2600,6502,1,1,56,3834,26
1507280297083,174,viewProduct,200,OK,JPetstore 1-1,text,true,,2643,6804,1,1,55,0,26
1507280292198,174,ViewProduct,200,"Number of samples in transaction : 1, number of failing samples : 0",JPetstore 1-1,,true,,2643,6804,1,1,55,4886,26
1507280301651,162,addItemToCart,200,OK,JPetstore 1-1,text,true,,2827,6824,1,1,54,0,25
1507280304617,169,newOrderForm,200,OK,JPetstore 1-1,text,true,,3026,6804,1,1,55,0,27
1507280306851,173,setBillingInfo,200,OK,JPetstore 1-1,text,true,,2759,8194,1,1,63,0,28
1507280310018,163,confirmOrder,200,OK,JPetstore 1-1,text,true,,2980,6475,1,1,56,0,26
我们将在本指南的后面部分看到如何使用保存到JTL文件中的结果进行进一步处理和深入分析。JTL是分析JMeter结果的最有效方法。
优点:
- JTL是普通的CSV文件,易于阅读,
- 一些基于Web的工具能够解析JTL文件并呈现在线报告,
- 所有原始结果都与JTL文件一起保存。
缺点:
- JTL由其磁盘上的每个负载生成器写入。分布式测试需要在测试结束时将它们带回控制器,
- JTL可能会变大(几GB)并使磁盘变得杂乱,
- 必须使用Excel等工具对JTL进行数据挖掘,以便从中获取有用的指标。
让我们看看我们如何解释这些JTL文件。
用Excel进行JTL分析
%APACHE_JMETER_HOME%/ extras包含几个xsl文件,这些文件专门用于处理XML格式的JTL文件并输出漂亮的报告。寻找以下文件:
- jmeter-results-detail-report_21.xsl:详细的JMeter报告,
- jmeter-results-report_21.xsl:基本JMeter报告。
下面的过程说明了如何使用这些XSL样式表和Microsoft Excel获得不错的报告。
如何用Excel分析JTL文件
- Simple Data Writer Listener:将其添加到测试计划中,将其配置为将结果保存为 JTL文件中的XML,
- 运行负载测试:从APACHE_JMETER_HOME运行命令
./bin/jmeter -n -t jpetstore.jmx -l jmeter.jtl
,
Creating summariser <summary>
Created the tree successfully using jpetstore.jmx
Starting the test @ Fri Oct 06 15:03:42 CEST 2017 (1507295022425)
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary + 12 in 00:00:18 = 0.7/s Avg: 187 Min: 30 Max: 418 Err: 2 (16.67%) Active: 2 Started: 2 Finished: 0
summary + 27 in 00:00:29 = 0.9/s Avg: 168 Min: 29 Max: 270 Err: 2 (7.41%) Active: 2 Started: 4 Finished: 2
summary = 39 in 00:00:47 = 0.8/s Avg: 173 Min: 29 Max: 418 Err: 4 (10.26%)
summary + 33 in 00:00:31 = 1.1/s Avg: 163 Min: 28 Max: 259 Err: 3 (9.09%) Active: 2 Started: 7 Finished: 5
summary = 72 in 00:01:18 = 0.9/s Avg: 169 Min: 28 Max: 418 Err: 7 (9.72%)
summary + 27 in 00:00:29 = 0.9/s Avg: 165 Min: 29 Max: 246 Err: 2 (7.41%) Active: 2 Started: 9 Finished: 7
summary = 99 in 00:01:47 = 0.9/s Avg: 168 Min: 28 Max: 418 Err: 9 (9.09%)
summary + 14 in 00:00:13 = 1.1/s Avg: 163 Min: 28 Max: 246 Err: 1 (7.14%) Active: 0 Started: 10 Finished: 10
summary = 113 in 00:02:00 = 0.9/s Avg: 167 Min: 28 Max: 418 Err: 10 (8.85%)
Tidying up ... @ Fri Oct 06 15:05:43 CEST 2017 (1507295143106)
... end of run
- 编辑JTL:添加
<?xml-stylesheet type="text/xsl" href="PATH_TO_jmeter-results-report_21.xsl"?>
之后<?xml version="1.0" encoding="UTF-8"?>
, - 保存JTL,
- 打开Microsoft Excel:然后拖放其中的JTL文件。
请注意,它不适用于Open Office。仅支持Microsoft Office。
借助新推出的JMeter报告仪表板,这一传统解决方案不再具有吸引力。与JMeter 3.0以来提供的新JMeter HTML报告相比,该报告看起来过时了。
HTML报告DashBoard
可以使用单独的命令行在测试结束时生成HTML报告仪表板。此报告非常丰富,并显示许多不同的指标。有关所有可自定义设置的完整列表,请参阅JMeter网站上的生成仪表板。
一旦你有一个包含所有结果的JTL,运行:
./bin/jmeter -g JTL_FILE -o OUTPUT_FOLDER
哪里:
- -g JTL_FILE:JTL文件的相对路径或完整路径。示例:jmeter.jtl,
- -o OUTPUT_FOLDER:应在其中写入HTML报告的文件夹。
命令行执行可能需要一段时间,具体取决于JTL文件大小。完成后,终端内不应显示任何错误。报告已在给定的输出文件夹中准备就绪。
优点:
- HTML报告很容易生成,
- 图表和表格设计得很好,
- 您可以在每个图表上选择/取消选择请求和/或交易。
缺点:
- 自定义设置太多,从哪里开始?
- 无法通过添加文本,图像等完全自定义报告。这是一份静态报告。
从JMeter 3.0开始,HTML Report Dashboard向前迈进了一大步,简化了JMeter测试结果分析。
报告摘要包含以下信息:
- 测试开始时间和结束时间,
- 每个请求和容器的APDEX分数,
- 一个名为Requests Summary的饼图,它给出了成功/失败样本的比例。
Statistics表为已执行的每个请求提供全局测试统计信息:
-
执行:命中和错误的数量,
- #Samples:执行的样本总数,
- KO:未能执行的总样本数,
- 错误%:错误百分比,
-
响应时间(ms):响应时间(以毫秒为单位)
- 平均值:平均经过时间,
- 最小值:最小经过时间,
- 最大:经过的最长时间,
- 第 90个百分点:第90百分位,
- 95th pct:95th Percentile,
- 第 99个百分点:第99百分位,
- 吞吐量:每秒点击次数,
-
网络:吞吐量,以KB /秒为单位
- 收到:每秒收到的 KB,
- 已发送:每秒发送的 KB。
这些行可以通过上面的任何统计信息进行排序,从而可以轻松找到导致瓶颈的请求。通过降低平均值来下达订单请求,您应该会在统计信息表中看到最慢的请求。
错误表提供了有关负载测试期间遇到的错误的更多详细信息。对于每种类型的错误,您将看到:
- 错误数:发生了多少错误,
- 错误百分比:错误请求的百分比,
- 所有样本中的百分比:与样本总数相比的错误百分比。
响应时间随时间变化图表
此图表显示整个测试过程中每笔交易的平均响应时间。遗憾的是,如果您有大量交易,图表可能看起来混乱,因为所有交易都显示在其上。
响应时间百分位数
活动线程,随时间的吞吐量
活动线程,随时间的吞吐量
还有许多其他图表:
-
吞吐量:
- 每秒点击次数(不包括嵌入式资源):每秒点击次数,
- 每秒代码数(不包括嵌入式资源):每秒HTTP代码数(200 OK,500内部错误等)
- 每秒事务数:每秒的事务(与事务控制器相关),
- 响应时间与请求:响应时间与每秒请求数相比,
- 延迟与请求:与每秒请求数相比的延迟,
-
响应时间:
- 响应时间百分位数:每百分位数的经过时间,以10%为增量,
- 响应时间概述:给出每个Apdex范围的请求百分比(满意,容忍和令人沮丧),
- 时间与线程:每个活动线程的经过时间,以查看负载增加时经过的时间如何降低,
- 响应时间分布:经过时间如何在最小和最大经过时间之间传播。
HTML报告显然是赶上一些昂贵工具(如LoadRunner或NeoLoad)的一个很好的步骤。当然,为了满足您的需求,可以更好地定制报告。无论如何,与集成的UI监听器相比,它在改进JMeter测试结果分析方面是一个巨大的飞跃。
考虑到JMeter是一个免费提供的开源负载测试工具,我很惊讶地看到有多少工具可以分析测试结果。我们还没完成!
后端听众
JMeter的Backend Listener允许插入外部数据库来存储测试结果和性能指标。
在本节中,我们将结合几个开源工具来实时收集和可视化JMeter结果:
- InfluxData:用作存储性能指标的临时指标存储的数据库,
- Grafana:Grafana是一个时间序列分析的开源平台,允许您根据时间序列数据创建实时图表,
- JMeter的后端监听器:后端监听器收集JMeter指标并将它们发送到临时指标存储。
公开指标
JMeter发送时间序列数据库的度量标准。下面的列表描述了可用的指标。
-
线程指标:
- ROOT_METRICS PREFIX test.minAT:最小活动线程,
- ROOT_METRICS PREFIX test.maxAT:最大活动线程,
- ROOT_METRICS PREFIX test.meanAT:平均活动线程,
- ROOT_METRICS PREFIX test.startedT:启动线程,
- ROOT_METRICS PREFIX test.endedT:完成的线程。
-
响应时间指标:
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ok.count:采样名称的成功回复数,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .h.count:服务器每秒点击次数,此指标累计样本结果和子结果(如果使用事务控制器,则应取消选中“生成父样本”),
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ok.min:采样名称成功回复的最短响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ok.max:采样名称成功回复的最长响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ok.avg:采样名称成功回复的平均响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ok.pct_PERCENTILE_VALUE:为采样器名称的成功响应计算的百分位数。每个计算值都有一个指标,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ko.count:采样名称的失败响应数,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ko.min:采样名称响应失败的最短响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ko.max:采样名称响应失败的最长响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ko.avg:采样名称响应失败的平均响应时间,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .ko.pct_PERCENTILE_VALUE:针对采样器名称的失败响应计算的百分位数。每个计算值都有一个指标,
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .a.count:采样器名称的响应数(ok.count和ko.count的总和),
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .a.min:采样名称响应的最短响应时间(ok.count和ko.count的最小值),
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .a.max:采样名称响应的最长响应时间(最大值为ok.count和ko.count),
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .a.avg:采样器名称响应的平均响应时间(平均值为ok.count和ko.count),
- ROOT_METRICS_PREFIX__ SAMPLER_NAME .a.pct_PERCENTILE_VALUE:针对采样器名称的响应计算的百分位数。每个计算值将有一个度量标准。(根据OK和失败样本的总计计算)。
以下常量是:
- ROOT_METRICS_PREFIX_:根指标前缀。使用InfluxBackendListenerClient时没有,
- SAMPLER_NAME:JMX脚本中示例的名称,
- PERCENTILE_VALUE:默认为90,95或99。取决于后端监听器配置。
InfluxDB安装程序
我们要下载并安装InfluxDB:
- 下载InfluxDB,
- 安装InfluxDB,这是使用A Debian包的Ubuntu的设置:
ubuntu@desktop:~$ wget https://dl.influxdata.com/influxdb/releases/influxdb_1.3.6_amd64.deb
ubuntu@desktop:~$ sudo dpkg -i influxdb_1.3.6_amd64.deb
Selecting previously unselected package influxdb.
(Reading database ... 264577 files and directories currently installed.)
Preparing to unpack influxdb_1.3.6_amd64.deb ...
Unpacking influxdb (1.3.6-1) ...
Setting up influxdb (1.3.6-1) ...
Created symlink from /etc/systemd/system/influxd.service to /lib/systemd/system/influxdb.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/influxdb.service to /lib/systemd/system/influxdb.service.
ubuntu@desktop:~$
InfluxDB设置可能因操作系统而异。有关更多信息,请参阅InfluxDB安装。
- 通过运行启动Influxdb服务
ubuntu@desktop:~$ sudo service influxdb start
, influx
在终端中运行命令以连接到数据库,- 创建JMeter的数据库:
ubuntu@desktop:~$ influx
Connected to http://localhost:8086 version 1.3.6
InfluxDB shell version: 1.3.6
> show databases
name: databases
name
----
_internal
> CREATE DATABASE jmeter
>
很棒,InfluxDB正在运行!
Grafana设置
Grafana是一个仪表板,可用于可视化JMeter发送到InfluxDB数据库的指标。
- 下载Grafana并安装它(Ubuntu设置在这里):
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.5.2_amd64.deb
sudo dpkg -i grafana_4.5.2_amd64.deb
- 浏览以
http://localhost:3000
打开grafana仪表板。使用admin
的登录名和密码。
- 选择Add DataSource选项,
-
然后使用以下设置配置DataSource:
- 名称:Influxdb,任何名称都应该有用,
- 输入:InfluxDB,当我们连接到InfluxDB数据库时,
- 网址:
http://localhost:8086/
, - 访问:直接,因为它直接连接到数据库,
- 数据库:jmeter,以前创建的数据库。
BackendListener设置
现在,让我们为我们的测试计划添加一个后端监听器:
- 打开JMeter,然后打开示例JMX Script,
- 右键单击测试计划,然后选择Add> Listener> Backend Listener,
-
使用以下设置配置后端侦听器:
- InfluxdbMetricsSender:用于将指标发送到InfluxDB的实现类。从JMeter 3.2开始,InfluxDB可以在不需要添加任何额外插件的情况下使用,
- InfluxDbUrl:InfluxDB数据库url,InfluxDB的url格式为:http:// [Influxdb_host]:[Influxdb_port] / write?db = [database_name]。由于我们已经创建了
jmeter
数据库,并且我们使用默认端口在本地计算机上运行它,因此在我们的示例中,url将是:http://127.0.0.1:8086/write?db=jmeter
- application:应用程序的名称。此参数允许按名称对度量标准进行分组,从而允许将相同的数据库用于多个不同的测试,
- 测量:将存储在InfluxDB中的测量名称(基于文本的行InfluxDB内部协议,用于存储指标)。对该属性使用默认的“jmeter”,
- summaryOnly:
false
如果你想在数据库中保留详细的指标, - samplesRegex:允许过滤采样器名称存储的结果,
- 百分位数:
90;95;99
默认情况下,定义正在处理并发送到InfluxDB的百分位数 - testTitle:我们在这里使用JPetstore,
- eventTags:将存储在InfluxDB的“事件”度量中的标记列表。
运行测试
现在,是时候在JMeter中运行测试了。在GUI或非GUI模式下启动测试。
要检查结果是否已正确发送到InfluxDB,请运行以下命令:
curl 'http://localhost:8086/query?pretty=true' --data-urlencode "db=jmeter" --data-urlencode "q=SHOW SERIES"
{
"results": [
{
"statement_id": 0,
"series": [
{
"columns": [
"key"
],
"values": [
...
[
"events,application=jpetstore,title=ApacheJMeter"
],
[
"jmeter,application=jpetstore,responseCode=0,responseMessage=Number\\ of\\ samples\\ in\\ transaction\\ :\\ 1\\,\\ number\\ of\\ failing\\ samples\\ :\\ 1,transaction=Home\\ page"
],
...
]
}
]
}
]
}
返回的Json文档应包含多个值。让我们配置一个Grafana仪表板来显示Hits / sec。
创建JMeter仪表板
- 选择创建您的第一个仪表板,
- 选择图表,
- 单击Panel Title然后编辑,
-
现在,让我们配置指标:
- 数据源:选择之前配置的InfluxDB数据源,
- FROM:默认jmeter,WHERE application = jpetstore,
- SELECT:字段计数 mean(),这是平均样本数,
- GROUP BY:时间($ _ interval) 填充(线性),以获得漂亮的折线图,
- 格式为:时间序列。
它应该生成下面屏幕截图中显示的图表。
使用JMeter BackendListener在Grafana中命中/秒图表
NovaTec APM仪表板
自己配置grafana仪表板是一项繁琐而艰巨的任务,特别是如果您没有查询指标的扩展知识。他们发布了预先配置的JMeter负载测试仪表板。
此仪表板仅适用于以下后端侦听器插件:JMeter InfluxDB Writer
安装JMeter InfluxDB Writer
- 从JMeter InfluxDB Writer下载页面下载插件,
- 复制插件JMETER_HOME / lib / ext,
- 重启JMeter。
创建专用数据库
此设置需要单独的数据库:
novatec
使用以下命令在InfluxDB中创建新数据库:
ubuntu@desktop:~$ curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE novatec"
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Request-Id: b04edfe5-acd4-11e7-8647-000000000000
X-Influxdb-Version: 1.3.6
Date: Mon, 09 Oct 2017 09:31:54 GMT
Transfer-Encoding: chunked
{"results":[{"statement_id":0}]}
配置JMeter InfluxDB Writer
- 打开JMeter,然后打开示例JMX Script,
- 右键单击测试计划,然后选择Add> Listener> Backend Listener,
-
使用以下设置配置后端侦听器:
- testName:jpetstore,
- nodeName:测试节点,
- 流入数据库:8086,
- 潮流DBUser:jmeter,
- 流入数据库密码:无,
- InfluxDBDatabase:novatec。
让其他设置使用默认设置。
JMeter BackendListener使用NovaTec InfluxDB Writer插件
在Grafana创建新的Data-Source Novatec
- 创建映射到数据库的新数据源
novatec
。
导入Novatec仪表板
请按照文档说明如何导入Grafana仪表板的详细信息。
- 打开Grafana,
- 选择导入新仪表板,
- 输入ID
1152
,即Novatec仪表板的ID, - 选择指向
novatec
数据库的数据源。
您应该能够在仪表板中看到动画图表。
JMeter Novatec Dashboard在Grafana
此仪表板通过图形,饼图等提供了许多有趣的指标:
- 活跃用户:当前正在运行的线程
- 总吞吐量:每秒操作数,
- 成功率:成功请求的百分比,
- 请求计数:执行的请求总数,
- 错误率:失败的请求百分比,
- 度量标准概述:显示所有度量标准的表,每个请求一行,
- 和更多!
InfluxDB Studio
InfluxDB Studio是InfluxDB的UI管理工具。它在Windows上运行,允许使用用户友好的UI管理InfluxDB数据库。
推荐的设置
我们强烈建议将NovaTec插件与NovaTec JMeter仪表板结合使用。它提供了一个开箱即用的仪表板,其中包含许多有趣的指标,可随时使用。自己配置Grafana可能很困难,需要了解InfluxDB查询的工作原理。
Saas JMeter解决方案
正如我们所看到的,使用BackendListener进行完整的工作设置可能需要相当长的时间来进行设置。我们甚至没有谈论维护和更新。这就是出现像OctoPerf,Blazemeter或Flood.io这样的云解决方案的原因。
这些Saas工具提供了运行JMeter测试和收集指标的工具。每个工具都有自己的基于专有技术的报告系统。我们将在这里探索每个工具并比较他们的报告功能。目标是概述每个JMeter云解决方案的报告功能。
每个工具将用于运行相同的测试:
- 20个并发用户,
- 10分钟的测试时间,
- 从任何可用免费帐户的位置。
请记住,我们正努力尽可能客观。市场上还有许多其他工具可用于JMeter结果分析。因此,我们只选择了最受欢迎的工具。
Blazemeter
Blazemeter是市场上第一款允许用户在云中扩展负载测试的工具。Blazemeter是一家由Alon Girmonsky于2011年12月创立的美国公司。
在Blazemeter上开始测试
总结报告
火焰计总结报告
摘要报告提供以下统计信息:
- 最大用户数:最大并发用户数,
- 平均吞吐量:每秒点击次数,
- 错误%:错误百分比,
- 平均响应时间:平均响应时间(以毫秒为单位),
- 90%响应时间:90%百分位响应时间,
- 平均带宽:测试期间每秒的平均KiB。
它包括两个图:
- 加载图:显示命中/秒,错误/秒和并发用户曲线,
- 响应时间图:显示并发用户和平均响应时间曲线。
摘要是静态的:无法添加或删除指标。
时间线报告
时间线报告
时间线报告提供了一个巨大的图表,其曲线可以自定义。可以单独选择和绘制交易。不保留采样器层次结构有点令人遗憾:所有事务和请求都在一个列表中。如果同时绘制许多请求,时间线可能会变得非常混乱。
请求统计
请求统计
请求统计信息提供了一个表,其中包含每个事务或请求的全局统计信息。以下统计数据可用:
- #样品:样品数量,
- 平均响应时间(毫秒):平均经过时间,以毫秒为单位,
- 第90行(ms):经过时间90%百分位,以毫秒为单位,
- 第95行(ms):经过时间的百分比为95%,以毫秒为单位,
- 第99行(ms):经过时间的百分比为99%,以毫秒为单位,
- 最小响应时间(毫秒):最短经过时间(以毫秒为单位),
- 最大响应时间(毫秒):最大经过时间(以毫秒为单位),
- 平均KiB /秒:网络吞吐量(下载),单位为KiloBytes /秒,
- 错误百分比:错误命中百分比。
整个表格可以下载为CSV文件进行外部处理。统计数据可以按时间过滤。
错误
错误报告
此报告显示测试运行期间收到的所有错误,按标签(页面)和错误类型分类。
JMeter日志
JMeter日志
每个引擎的JMeter日志都可用。可以直接在浏览器中下载或查看日志。
原始测试配置
原始测试配置
本节提醒原始测试配置。
执行摘要
执行摘要
执行摘要是测试报告的可打印版本。它包含前面部分中的所有内容(摘要,TimeLine等)。
洪水
洪水是Blazemeter的挑战者。这家澳大利亚公司由Ivan Vanderbyl和Tim Koopsman于2013年9月创立。它们提供与BlazeMeter几乎相同的功能:上传您的JMX脚本,运行测试并分析结果。
对洪水IO的启动测试
时间线
TimeLine包含一个包含可选事务的主图
TimeLine概述了测试结果指标。您可以通过在下表中选择它来绘制单个交易指标。
JMeter日志
JMeter记录实时尾部和下载
在测试运行时,可以实时查看JMeter日志。可以在测试结束时下载日志。
请求详情
交易/请求详情
通过选择单个请求或事务,您可以访问子报告,该报告提供有关该事务的大量指标。(平均值,最小值,最大值,标准偏差,百分位数,传递与失败等等)在负载测试期间,一些随机点也会存储一些请求和响应。
杂
度量标准可以作为CSV文件下载以进行外部处理。
OctoPerf
OctoPerf是一家成立于2016年9月的法国负载测试公司.OctoPerf的报告系统是一个可定制的模块化系统。可以重新排列以下任何报告项目,从而使报告系统动态化。该报告已预先配置了某些报告项目。可以根据需要添加或删除项目。
在OctoPerf上开始测试
有关更多信息,请阅读有关报告项目的文档。
测试摘要
测试摘要
测试摘要显示有关测试配置的详细信息,如:
- 测试时间,
- 并发用户数,
- 使用的地理位置,
- 和更多。
统计摘要
统计摘要
统计摘要提供测试范围统计。可以自定义以下设置:
- 显示的统计数量,
- 要包含的统计数据。
有30多个指标可供使用。
图表
OctoPerf报告系统可以提供无限数量的图表,每个图表配置不同。每个图形都有可自定义的曲线,每个图形从1到4条曲线。即使在同一图表上,您也可以绘制性能指标和监控指标的图表。
结果表
结果表提供每个事务或请求的全局统计信息。
阈值
阈值表显示测试期间发生的阈值警告和错误。阈值与监视功能相关联。监控允许您捕获后端服务器监控指标。
顶部图表
顶部图表项为给定指标提供容器或http请求的顶部。此图表非常适合深入查找慢速业务事务和/或请求。
饼形图
饼图有助于快速了解HTTP响应代码,HTTP方法和HTTP响应媒体类型重新分区。它允许快速发现Web应用程序是否按预期运行。
百分
百分位数图表显示了一定百分比的观测值出现的点。例如,第95百分位数是大于观察值的95%的值。
错误表
错误表提供有关测试期间发生的每个错误的详细信息。它允许了解负载测试期间服务器端发生的情况。
每个错误的细节
对于每个记录的错误,您可以查看从服务器发送的请求和响应。
JMeter JTL和日志
OctoPerf允许您在执行虚拟用户验证或负载测试后查看JMeter日志。您还可以通过单击“下载”按钮下载完整的日志文件。单击它时会下载.log.gz。您需要像7Zip这样的文件压缩工具来提取它。
JMeter JTL文件在测试结束时也会自动集中。
比较表
你猜怎么着?我们编制了一个比较表,直接比较了市场上前三大的JMeter云解决方案:
OctoPerf | Blazemeter | Flood.io | |
录音机 | |||
HAR进口 | |||
单个URL / REST | |||
Jmeter导入 | |||
加特林进口 | |||
相关性 | 在Jmeter | 在Jmeter | |
变量 | 在Jmeter | 在Jmeter | |
验证脚本 | 在Jmeter | 在Jmeter | |
主机文件覆盖 | |||
SLA | |||
沙箱(免费单元测试) | 每月100次测试 | 仅限10项测试 | 仅5个小时 |
带宽仿真 | 全球唯一 | ||
延迟仿真 | 全球唯一 | ||
想想时间 | 全球唯一 | 在Jmeter | |
起搏 | |||
减速 | |||
命中和RPS加载策略 | 在Jmeter | ||
真正的浏览器监控 | |||
LG启动和配置 | 自动 | 手册 | 手册 |
LG监控 | |||
一次测试中有几个JMX | |||
预测试 | |||
实时过滤器 | |||
持续时间筛选 | |||
自动SLA | Apdex的 | Apdex的 | |
保留IP | |||
默认视图 | 好 | 好 | 平均 |
整体可用性 | 好 | 平均 | 平均 |
协作访问 | |||
日志 | |||
错误详情 | 有详细信息 | ||
可编辑的图表 | 只有一个图表 | ||
导出PDF | |||
导出CSV | 通过JTL | ||
自定义报告文本 | |||
对照 | |||
趋势 | |||
报告公共链接 | |||
报告可用性 | 无限 | 1周到无限制 | 1至12个月 |
Jmeter版本 | 支持最新的Jmeter版本 | 支持几种Jmeter版本 | 仅限Jmeter的一个版本,目前不是最新版本(3.1而不是3.3) |
请随意询问其他功能,以便从评论中进行检查。
摘要
收集和显示JMeter性能指标有许多不同的方法。从DIY开源工具到专有解决方案,每个人都有一个解决方案。你应该使用哪种解决方案?这是一个简短的总结。
- UI Listeners:非常适合调试目的,您可以将它们用于非常小的负载测试(低于50个并发用户),
- JTL文件+简单数据写入器:此解决方案可用于分布式测试,但配置可能很繁琐。然后可以使用JMeter XSL表或HTML报告分析JTL文件,
- 后端监听器+ InfluxDB + Grafana:该解决方案消除了在分布式测试中收集和合并JTL文件的繁琐工作。它还在测试期间提供实时指标。但设置很困难,需要先进的知识,必须维护多个系统,
- Saas解决方案:最简单,最强大的解决方案,但您必须为大多数平台上超过50个并发用户的测试付费。您可以在测试设置和结果分析上节省大量时间。
所选择的解决方案高度依赖于以下因素:
- 时间:负载测试阶段是否按时紧固?
- 预算:是否有分配预算来支付负载测试费用?预算多少钱?
- 专业知识:您在负载测试领域拥有多少专业知识?
开源和DIY解决方案通常是免费的,但需要花费大量时间。专有解决方案需要成本,但更有效。无论您有时间,预算还是两者,都有适合每个人的解决方案。