概述
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以內。
下一篇文章，我們將通過實際專案來演示監聽器在效能測試中的用法，同時分析一些效能瓶頸。
同時會有視訊公開課，用視訊講解的方式來給大家實際講解哦！
可以新增微信：14751700162
或者聯絡QQ：1144890271
