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

Java 8，
JMeter 3.3或以上。

在整個指南中，使用如下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。

打開瀏覽器，而後導航到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數據庫。

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個併發用戶的測試付費。您能夠在測試設置和結果分析上節省大量時間。

所選擇的解決方案高度依賴於如下因素：