[转帖]JMETER结果分析

jmeter,结果,分析 · 浏览次数 : 0

小编点评

## 总结 * 您可以根据需要选择不同的解决方案进行负载测试。 * 每个解决方案都有其优缺点，需要根据您的具体情况进行选择。 * 您可以使用DIY开源工具、专有解决方案、或SaaS解决方案进行负载测试。 * 选择最适合您的解决方案的关键在于时间、预算、专业知识、开源和DIY的成本。 * 您可以通过优化解决方案节省大量时间。

正文

https://www.cnblogs.com/a00ium/p/10462892.html

我相信你同意：有很多方法可以收集和解释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模式下运行至关重要。

运行演示应用程序

要在您自己的计算机上运行演示应用程序，您需要：

与Docker兼容的操作系统，有关详细信息，请参阅Docker安装，
Docker。

要运行JPetstore演示应用程序，只需执行命令行即可docker run -d -p 8080:8080 jloisel/jpetstore6。

JPetstore演示

打开浏览器，然后导航到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放置听众

根据结果监听器的放置位置，它会收集不同的指标。JMeter结果侦听器从同一级别或更低级别的所有元素收集结果。因此，建议将监听器置于测试计划级别以收集所有线程组结果。

查看结果树

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

我建议使用这个监听器：

在将测试扩展到大量并发用户之前调试脚本，
通过为一次迭代运行单个线程组来定义基准性能指标，
和/或使用收到的响应来修复/设计后处理器以提取动态参数。

聚合图

JMeter聚合图

JMeter聚合图设置

聚合图是一个UI Listener，它为每个请求和事务控制器提供了一些有用的测试范围指标。它还包括一个条形图，可以通过许多不同的设置进行调整以满足您的需求。我必须说，有太多的设置，更糟糕的是，这些设置都没有保存在JMX中。关闭JMeter时松开它们。

虽然，我必须承认能够将图表导出为PNG并将表格导出为CSV以便将来在自定义设计的报告中使用，这非常好。

度量标准是测试范围的，这意味着您可以获得整个测试请求的平均响应时间。可用的指标是：

标签：请求的名称，
#Samples：执行总数，
平均值：平均经过时间，以毫秒为单位，
中位数：中位数是将数据样本的较高一半，人口或概率分布与下半部分隔开的值。对于数据集，它可以被认为是“中间”值，
90％线：90％百分位，百分位数（或百分位数）是统计中使用的一种度量，表示一组观察中给定百分比的观察值下降的值，
95％线：95％百分位，
99％线：99％百分位，
最小值：最小经过时间，
最大：经过的最长时间，
错误％：错误百分比（错误/（错误+样本）* 100），
吞吐量：每秒样本数，
和KB /秒：网络吞吐量，单位为千片/秒。

与任何其他UI Listener一样，我不建议将其用于实际负载测试。

汇总报告

JMeter聚合图

聚合报告与聚合图非常相似，仅包含度量表。在运行无头负载测试（没有启动UI）时可以使用此侦听器，因为统计信息可以保存在CSV文件中供以后使用。它包含与聚合图完全相同的指标。然后，可以使用这些度量来使用Word编写报告。

生成摘要结果

JMeter摘要结果设置

JMeter摘要结果监听器在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图表结果

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简单数据编写器

这是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，

JMeter简单数据编写器另存为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文件。

JMeter Excel报告

请注意，它不适用于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测试结果分析。

JMeter HMTL报告摘要

报告摘要包含以下信息：

测试开始时间和结束时间，
每个请求和容器的APDEX分数，
一个名为Requests Summary的饼图，它给出了成功/失败样本的比例。

JMeter HMTL报告统计

Statistics表为已执行的每个请求提供全局测试统计信息：

执行：命中和错误的数量，
- #Samples：执行的样本总数，
- KO：未能执行的总样本数，
- 错误％：错误百分比，
响应时间（ms）：响应时间（以毫秒为单位）
- 平均值：平均经过时间，
- 最小值：最小经过时间，
- 最大：经过的最长时间，
- 第 90个百分点：第90百分位，
- 95th pct：95th Percentile，
- 第 99个百分点：第99百分位，
- 吞吐量：每秒点击次数，
网络：吞吐量，以KB /秒为单位
- 收到：每秒收到的 KB，
- 已发送：每秒发送的 KB。

这些行可以通过上面的任何统计信息进行排序，从而可以轻松找到导致瓶颈的请求。通过降低平均值来下达订单请求，您应该会在统计信息表中看到最慢的请求。

JMeter HMTL报告错误

错误表提供了有关负载测试期间遇到的错误的更多详细信息。对于每种类型的错误，您将看到：

错误数：发生了多少错误，
错误百分比：错误请求的百分比，
所有样本中的百分比：与样本总数相比的错误百分比。

JMeter随时间的响应时间响应时间随时间变化图表

此图表显示整个测试过程中每笔交易的平均响应时间。遗憾的是，如果您有大量交易，图表可能看起来混乱，因为所有交易都显示在其上。

JMeter随时间的响应时间响应时间百分位数

JMeter活动线程和吞吐量活动线程，随时间的吞吐量

JMeter延迟和连接时间活动线程，随时间的吞吐量

还有许多其他图表：

吞吐量：
- 每秒点击次数（不包括嵌入式资源）：每秒点击次数，
- 每秒代码数（不包括嵌入式资源）：每秒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的登录名和密码。

Grafana登录

选择Add DataSource选项，

Grafana添加数据源

然后使用以下设置配置DataSource：
- 名称：Influxdb，任何名称都应该有用，
- 输入：InfluxDB，当我们连接到InfluxDB数据库时，
- 网址：http://localhost:8086/，
- 访问：直接，因为它直接连接到数据库，
- 数据库：jmeter，以前创建的数据库。

Grafana配置数据源

BackendListener设置

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）填充（线性），以获得漂亮的折线图，
- 格式为：时间序列。

它应该生成下面屏幕截图中显示的图表。

Grafana配置图使用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 InfluxDB Writer插件 JMeter BackendListener使用NovaTec InfluxDB Writer插件

在Grafana创建新的Data-Source Novatec

创建映射到数据库的新数据源novatec。

导入Novatec仪表板

请按照文档说明如何导入Grafana仪表板的详细信息。

打开Grafana，
选择导入新仪表板，
输入ID 1152，即Novatec仪表板的ID，
选择指向novatec数据库的数据源。

您应该能够在仪表板中看到动画图表。

JMeter Grafana Novatec仪表板 JMeter Novatec Dashboard在Grafana

此仪表板通过图形，饼图等提供了许多有趣的指标：

活跃用户：当前正在运行的线程
总吞吐量：每秒操作数，
成功率：成功请求的百分比，
请求计数：执行的请求总数，
错误率：失败的请求百分比，
度量标准概述：显示所有度量标准的表，每个请求一行，
和更多！

InfluxDB Studio

InfluxDB Studio是InfluxDB的UI管理工具。它在Windows上运行，允许使用用户友好的UI管理InfluxDB数据库。

Saas JMeter解决方案

正如我们所看到的，使用BackendListener进行完整的工作设置可能需要相当长的时间来进行设置。我们甚至没有谈论维护和更新。这就是出现像OctoPerf，Blazemeter或Flood.io这样的云解决方案的原因。

这些Saas工具提供了运行JMeter测试和收集指标的工具。每个工具都有自己的基于专有技术的报告系统。我们将在这里探索每个工具并比较他们的报告功能。目标是概述每个JMeter云解决方案的报告功能。

每个工具将用于运行相同的测试：

20个并发用户，
10分钟的测试时间，
从任何可用免费帐户的位置。

请记住，我们正努力尽可能客观。市场上还有许多其他工具可用于JMeter结果分析。因此，我们只选择了最受欢迎的工具。

Blazemeter

Blazemeter是市场上第一款允许用户在云中扩展负载测试的工具。Blazemeter是一家由Alon Girmonsky于2011年12月创立的美国公司。

Blazemeter开始测试在Blazemeter上开始测试

总结报告

火焰计总结报告

摘要报告提供以下统计信息：

最大用户数：最大并发用户数，
平均吞吐量：每秒点击次数，
错误％：错误百分比，
平均响应时间：平均响应时间（以毫秒为单位），
90％响应时间：90％百分位响应时间，
平均带宽：测试期间每秒的平均KiB。

它包括两个图：

加载图：显示命中/秒，错误/秒和并发用户曲线，
响应时间图：显示并发用户和平均响应时间曲线。

摘要是静态的：无法添加或删除指标。

时间线报告

Blazemeter TimeLine报告时间线报告

时间线报告提供了一个巨大的图表，其曲线可以自定义。可以单独选择和绘制交易。不保留采样器层次结构有点令人遗憾：所有事务和请求都在一个列表中。如果同时绘制许多请求，时间线可能会变得非常混乱。

请求统计

Blazemeter请求统计请求统计

请求统计信息提供了一个表，其中包含每个事务或请求的全局统计信息。以下统计数据可用：

＃样品：样品数量，
平均响应时间（毫秒）：平均经过时间，以毫秒为单位，
第90行（ms）：经过时间90％百分位，以毫秒为单位，
第95行（ms）：经过时间的百分比为95％，以毫秒为单位，
第99行（ms）：经过时间的百分比为99％，以毫秒为单位，
最小响应时间（毫秒）：最短经过时间（以毫秒为单位），
最大响应时间（毫秒）：最大经过时间（以毫秒为单位），
平均KiB /秒：网络吞吐量（下载），单位为KiloBytes /秒，
错误百分比：错误命中百分比。

整个表格可以下载为CSV文件进行外部处理。统计数据可以按时间过滤。

错误

Blazemeter错误报告错误报告

此报告显示测试运行期间收到的所有错误，按标签（页面）和错误类型分类。

JMeter日志

Blazemeter JMeter日志 JMeter日志

每个引擎的JMeter日志都可用。可以直接在浏览器中下载或查看日志。

原始测试配置

Blazemeter JMeter日志原始测试配置

本节提醒原始测试配置。

执行摘要

Blazemeter JMeter日志执行摘要

执行摘要是测试报告的可打印版本。它包含前面部分中的所有内容（摘要，TimeLine等）。

洪水

洪水是Blazemeter的挑战者。这家澳大利亚公司由Ivan Vanderbyl和Tim Koopsman于2013年9月创立。它们提供与BlazeMeter几乎相同的功能：上传您的JMX脚本，运行测试并分析结果。

洪水启动试验对洪水IO的启动测试

时间线

洪水时间线 TimeLine包含一个包含可选事务的主图

TimeLine概述了测试结果指标。您可以通过在下表中选择它来绘制单个交易指标。

JMeter日志

Flood JMeter日志 JMeter记录实时尾部和下载

在测试运行时，可以实时查看JMeter日志。可以在测试结束时下载日志。

请求详情

Flood JMeter日志交易/请求详情

通过选择单个请求或事务，您可以访问子报告，该报告提供有关该事务的大量指标。（平均值，最小值，最大值，标准偏差，百分位数，传递与失败等等）在负载测试期间，一些随机点也会存储一些请求和响应。

杂

度量标准可以作为CSV文件下载以进行外部处理。

OctoPerf

OctoPerf是一家成立于2016年9月的法国负载测试公司.OctoPerf的报告系统是一个可定制的模块化系统。可以重新排列以下任何报告项目，从而使报告系统动态化。该报告已预先配置了某些报告项目。可以根据需要添加或删除项目。

OctoPerf开始测试在OctoPerf上开始测试

有关更多信息，请阅读有关报告项目的文档。

测试摘要

OctoPerf测试摘要测试摘要

测试摘要显示有关测试配置的详细信息，如：

测试时间，
并发用户数，
使用的地理位置，
和更多。

统计摘要

OctoPerf统计摘要统计摘要

统计摘要提供测试范围统计。可以自定义以下设置：

显示的统计数量，
要包含的统计数据。

有30多个指标可供使用。

图表

OctoPerf命中和响应时间图

OctoPerf图

OctoPerf监控图

OctoPerf报告系统可以提供无限数量的图表，每个图表配置不同。每个图形都有可自定义的曲线，每个图形从1到4条曲线。即使在同一图表上，您也可以绘制性能指标和监控指标的图表。

结果表

OctoPerf结果表

结果表提供每个事务或请求的全局统计信息。

阈值

OctoPerf阈值

阈值表显示测试期间发生的阈值警告和错误。阈值与监视功能相关联。监控允许您捕获后端服务器监控指标。

顶部图表

OctoPerf顶部图表

顶部图表项为给定指标提供容器或http请求的顶部。此图表非常适合深入查找慢速业务事务和/或请求。

饼形图

OctoPerf饼图

饼图有助于快速了解HTTP响应代码，HTTP方法和HTTP响应媒体类型重新分区。它允许快速发现Web应用程序是否按预期运行。

百分

OctoPerf Percentiles

百分位数图表显示了一定百分比的观测值出现的点。例如，第95百分位数是大于观察值的95％的值。

错误表

OctoPerf错误表

错误表提供有关测试期间发生的每个错误的详细信息。它允许了解负载测试期间服务器端发生的情况。

OctoPerf错误详细信息每个错误的细节

对于每个记录的错误，您可以查看从服务器发送的请求和响应。

JMeter JTL和日志

OctoPerf JMeter日志

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解决方案通常是免费的，但需要花费大量时间。专有解决方案需要成本，但更有效。无论您有时间，预算还是两者，都有适合每个人的解决方案。