jmeter經常使用的性能測試監聽器

概述

jmeter中提供了不少性能數據的監聽器，咱們經過監聽器能夠來分析性能瓶頸

本文以500線程的階梯加壓測試結果來描述圖表。

 

經常使用監聽器

1：Transactions per Second

監聽動態TPS，用來分析吞吐量。其中橫座標是運行時間，縱座標是TPS值。紅色表示經過的TPS，綠色表示失敗的。

最大TPS大約在140左右，從1分26秒左右，開始有未經過的事物

 

2：Hits per Second

動態監聽單位時間的點擊率，也就是觸發的請求數。其中橫座標是運行時間，縱座標是HPS值。

點擊率波動較大，且不能持續上升。說明性能很不穩定

3：Response Times Over Time

監聽整個事物運行期間的響應時間。其中橫座標是運行時間，縱座標是響應時間（單位是毫秒）

響應時間在4950ms左右開始穩定下來，後續又經歷一次大的波動

4：Response Times vs Threads

線程活動期間的響應時間監聽。其中橫座標是活動的線程數（也就是併發數），縱座標是響應時間（單位是毫秒）

5： Active Threads Over Time

監聽單位時間內活動的線程數。其中橫座標是單位時間（單位是毫秒），縱座標是活動線程數（也就是併發數）

6：Response Times Percentiles

監聽響應時間分佈的百分比。其中橫座標是請求數的百分比，縱座標是響應時間。此圖表示有99.7%的請求響應時間在5s之內。

7：Response Times Distribution

響應時間分佈的柱狀圖。其中橫座標是柱狀分佈圖，縱座標是響應時間。此圖表示大約有111個請求響應時間在5076ms。

8：Composite Graph

組合式的監聽器。其中橫座標是運行時間，縱座標是各性能數據的彙總值（其中有一些數據須要除以10）。

總結

不一樣的監聽器能夠監聽不一樣的性能數據，可是想要在圖表中直觀的分析出性能的瓶頸，就須要組合式的監聽器。例如經過響應時間和吞吐量的分佈得出吞吐量的拐點。

經過以上圖表能看出來，在持續加壓的事物場景中，99.7%的請求響應時間都控制在了5s之內。

 

轉：http://www.javashuo.com/article/p-bgmtqcea-o.html