在進行效能測試時，JMeter是一款備受推崇的開源工具。而其中的聚合報告（Aggregate Report）是我們分析測試結果、瞭解系統效能的重要依據。今天，我們就來深入探討如何讀懂JMeter聚合報告中的各項引數。
面對複雜的聚合報告，究竟哪些引數是我們必須關注的？這些引數背後又隱藏著怎樣的重要資訊？
JMeter聚合報告包含多項關鍵引數，以下是從執行緒組引數及其解釋，透過實際案例配置幫助我們更好地理解這些資料：
執行緒組引數解釋
- 執行緒數（即併發數）：
一個使用者佔一個執行緒，200個執行緒就是模擬200個使用者；
- Ramp-Up 時間(秒)：
設定執行緒需要多長時間全部啟動；如果執行緒數為200，準備時長為10，那麼需要1秒鐘啟動20個執行緒；也就是每秒鐘啟動20個執行緒；
- 迴圈次數：
一次場景下來，請求的數量=執行緒數 * 迴圈次數；如果執行緒數為200，迴圈次數為10 ，那麼每個執行緒傳送10次請求；總請求數為200*10=2000 ；如果勾選了“永遠”，那麼所有執行緒會一直髮送請求，直到選擇停止執行指令碼；
JMeter聚合報告引數解釋
- Label：每個JMeter的element的Name值，例如HTTP Request的Name；
- 樣本：發出請求數量；模擬20個使用者，迴圈100次，所以顯示了2000；
- 平均值：平均響應時間（單位：ms）；預設是單個Request的平均響應時間，當使用了Transaction Controller時，也可以以Transaction為單位顯示平均響應時間；
- 中位數：50%的使用者響應時間小於這個值；
- 95%百分位：95%的使用者響應時間小於這個值；
- 99%百分位：99%的使用者響應時間小於這個值；
- 最小值：使用者響應時間最小值；
- 最大值：使用者響應時間最大值；
- 異常%：測試出現的錯誤請求數量百分比；請求的錯誤率 = 錯誤請求的數量/請求的總數；若出現錯誤就要看服務端的日誌查詢定位原因；
- 吞吐量：Throughput簡稱TPS，吞吐量，預設情況下表示每秒處理的請求數，也就是指伺服器處理能力，TPS越高說明伺服器處理能力越好；
- KB/sec：每秒從伺服器端接收到的資料量；
壓測結果分析
異常%：確認是否允許錯誤的發生或者錯誤率允許在多大的範圍內；
吞吐量：吞吐量每秒請求的數大於併發數，則可以慢慢的往上面增加；若在壓測的機器效能很好的情況下，出現吞吐量小於併發數，說明併發數不能再增加了，可以慢慢的往下減，找到最佳的併發數；
最大的TPS：不斷的增加併發數，加到TPS達到一定值開始出現下降，那麼那個值就是最大的TPS；
最大的併發數：最大的併發數和最大的TPS是不同的機率，一般不斷增加併發數，達到一個值後，伺服器出現請求超時，則可認為該值為最大的併發數；
壓測的時候要時刻關注應用伺服器資料庫伺服器等CPU、記憶體、網路等使用情況；
壓測過程出現效能瓶頸，若壓測客戶端工作管理員檢視到的CPU、網路和CPU都正常，未達到90%以上，則可以說明伺服器有問題，壓測客戶端沒有問題；
影響效能考慮點包括：資料庫、應用程式、中介軟體（php-fpm、nginx、redis…）、網路和作業系統等方面；
迴圈控制器
目的：迴圈該控制器下面子節點的次數。
執行緒組裡迴圈次數設定了n次，迴圈控制器下的迴圈次數也設定了m次，則該控制器下的請求執行的次數是（n*m）次。
如果（If）控制器
目的：判斷條件，可以引用變數。當為 true 時，執行子節點
Interpret Condition as Variable Expression?
如果選擇了此項，則條件必須是一個表示式，需要使用 ${__jexl3 } 或 ${__groovy } 表示式）
Evaluate for all children
勾選：對所有采樣器執行前都判斷一次
不勾選：僅入口判斷一次
如果是字串的比較，需要加””
"${url}"=="baidu"
注意事項：
在if邏輯控制器的Expression中不能直接填寫條件表示式，需要藉助函式將條件表示式計算為true/false，可以藉助的函式有__jexl3和__groovy函式
隨著網際網路和移動應用的發展，使用者對於系統響應速度和穩定性的要求越來越高。效能測試和分析變得越來越重要，而JMeter聚合報告提供了詳盡的資料，幫助我們全面瞭解系統的效能瓶頸和改進方向。
讀懂JMeter聚合報告引數，不僅能幫助我們準確評估系統效能，還能為後續的最佳化提供重要依據。透過深入分析每一個引數，我們能夠全面瞭解系統在不同負載下的表現，找到效能瓶頸，並制定相應的最佳化方案。
效能測試不僅是發現問題的手段，更是提升系統穩定性和使用者體驗的關鍵。掌握JMeter聚合報告的解析技巧，讓我們在效能最佳化的道路上更加從容自信，助力系統達到最佳表現。
