JMETER结果分析

时间  2021-02-18
标签 html java node git github docker shell 数据库 apache json 栏目 HTML 繁體版
原文   原文链接

我相信你赞成：有不少方法能够收集和解释JMeter结果，你会感到迷茫。html

嗯，看完这篇文章后，您将了解收集和分析结果的12种不一样方法！java

咱们将探索每种可能的方式来得到富有洞察力的指标，包括图形，图表，表格，HTML报告等。JMeter是一个如此复杂的工具，有不少惊人的可能性，很难知道该怎么作。node

关于如何分析JMeter结果的最终指南将启动您的JMeter知识。git

先决条件

安装

本教程假设您已经安装了如下软件：github

在整个指南中，使用如下Sample JMX。这个JMX 基于Docker Image中捆绑的Java JPetstore 测试咱们的演示应用程序。docker

了解JMeter指标

JMeter Metrics在如下部分中被普遍使用，所以若是您对其定义感到满意，则会更好：shell

  • 通过的时间：测量从发送请求以前到刚收到响应的最后一个块以后的通过时间，
  • 延迟：测量从发送请求以前到收到响应的第一个块以后的延迟，
  • 链接时间：测量创建链接所需的时间，包括SSL握手，
  • 中位数：将样本分红两等份的数字，
  • 90％线（90％百分位数）：通过的时间低于90％的样本降低，
  • 标准误差：测量数据集的可变性。这是一项标准统计指标，

  • 线程名称：派生自线程组名称和组内的线程。名称的格式为groupName +“”+ groupIndex +“ - ”+ threadIndex其中：数据库

    • groupName：线程组元素的名称，
    • groupIndex：测试计划中的线程组编号，从1开始，
    • threadIndex：线程组中线程的编号，从1开始。

  • 吞吐量：按请求/时间单位计算。时间从第一个样品的开始到最后一个样品的结束计算。公式为：吞吐量=（请求数）/（总时间）。apache

解释JMeter指标

你怎么知道一个指标是使人满意仍是糟糕？如下是一些解释：json

  • 通过时间/链接时间/延迟：应尽量低，理想状况下小于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监听器是：

简单的数据编写者

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数据库的指标。

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

建立专用数据库

此设置须要单独的数据库：

  • 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数据库。

咱们强烈建议将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开始测试在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解决方案一般是免费的，但须要花费大量时间。专有解决方案须要成本，但更有效。不管您有时间，预算仍是二者，都有适合每一个人的解决方案。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程