概述
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以內。
性能指標監聽
概述
性能測試過程中，想要得到比較靠譜的性能數據，就不得不對各種性能數據進行動態監聽。jmeter中提供了很多性能數據的監聽器，我們通過監聽器可以來分析性能瓶頸
本文以500線程的逐漸加壓測試結果來描述圖表（壓測百度）
常用監聽器
Transactions per Second
監聽動態TPS，用來分析吞吐量。其中橫坐標是運行時間，縱坐標是TPS值。紅色表示通過的TPS，綠色表示失敗的。
可以看出在56s左右，tps達到最高點1202/s，之后開始直線下降。
Hits per Second
動態監聽單位時間的點擊率，也就是觸發的請求數。其中橫坐標是運行時間，縱坐標是HPS值。
可以看出在58s的時候，點擊率出現波動；一分鍾的時候，點擊率達到最大（996/s），之后直線下降
Response Times Over Time
監聽整個事物運行期間的響應時間。其中橫坐標是運行時間，縱坐標是響應時間（單位是毫秒）
響應時間在達到3233ms之后左右開始急劇上升，此處就是性能瓶頸
Response Times vs Threads
線程活動期間的響應時間監聽。其中橫坐標是活動的線程數（也就是並發數），縱坐標是響應時間（單位是毫秒）
Active Threads Over Time
監聽單位時間內活動的線程數。其中橫坐標是單位時間（單位是毫秒），縱坐標是活動線程數（也就是並發數）
Response Times Percentiles
監聽響應時間分布的百分比。其中橫坐標是請求數的百分比，縱坐標是響應時間。此圖表示有90%的請求響應時間在270ms以內。
Response Times Distribution
響應時間分布的柱狀圖。其中橫坐標是柱狀分布圖，縱坐標是響應時間。
Composite Graph!
組合式的監聽器。其中橫坐標是運行時間，縱坐標是各性能數據的匯總值（其中有一些數據需要除以10）
此圖表示運行到一分鍾左右，吞吐量達到瓶頸點，之后吞吐量急劇下降，響應時間急劇上升
這里是對每個插件的用處進行解釋：
PerfMon Metrics Collector：用於監控機器的CPU、Memory、swap、Disks I/O、Networks I/O。CPU：cpu占用量百分比；
Memory：存儲量的使用情況；swap：交換區的使用情況；Disks I/O：磁盤I/O；Networks I/O：網絡I/O
Hits per Second：每秒測試計划所產生的點擊服務器的次數。
Bytes Throughput Over Time：在壓力測試期間接收和發送的bytes數。
Composite Graph：將你的測試計划中的所有圖表集合在同一張圖表中以方便查看。
Response Codes per Second：每秒返回的響應碼，表明jmeter測試期間，隨着時間的推移返回的響應碼，從中我們可以看到測試期間在哪個時間段內出現了錯誤，就可以分析在該時間內系統的什么環境因素導致的錯誤。
Response Latencies Over Time：每秒鍾的響應等待時間，表明jmeter測試期間，隨着時間的推移，系統的響應等待時間的變化，也是系統隨着時間推移系統效率的變化。
Response Times Distribution：響應時間分布，X軸表示的是響應時間，Y軸表示的是響應次數，F（X,Y）表示系統在某種響應時間次數是多少，如果響應時間短的地方，響應次數多，說明系統的效率越高。
Response Times Over Time：每秒鍾響應時間，X軸表示的是系統運行的時刻，Y軸表示的是響應時間，F（X,Y）表示系統隨着時間的推移，系統的響應時間的變化，可以看出響應時間的穩定性。
Response Times Percentiles：響應時間的百分比，X軸表示的是百分比，Y軸表示的是響應時間，F（X,Y）表示低於某個百分比的響應時間，比如有80%的響應低於400ms。
Response Times vs Threads：響應時間用戶數，X軸表示的是活動線程數，也就是並發訪問的用戶數，Y軸表示的是響應時間，F（X,Y）表示在某種並發量的情況下，系統的響應時間是多少。
Transaction Throughput vs Threads：每個活動線程數的事務吞吐量，X軸表示的是活動線程數，Y軸表示的是事務吞吐量，F（X,Y）的含義是當系統處於某個活動線程數時，系統當時的事務吞吐量是多少，比如當有10個活動線程時，事務吞吐量是100/s，而當有20個活動線程時，事務吞吐量是50/s，說明隨着用戶訪問的增加，系統的處理效率開始下降了，從這個圖中可以找到一個臨界點，在多大的活動線程數時，系統達到最大的吞吐量。
Transactions per Second：每秒的事務數，X軸表示訪問結束的時刻，Y軸表示訪問量，F（X,Y）表示在某個結束時刻，一共有多少的訪問量結束訪問。
Active Threads Over Time：每秒的活動線程數，X軸表示訪問的時刻，Y軸表示活動線程數，F（X,Y）表示某個時刻的活動線程數