Jmeter壓力測試隨筆記錄：並發測試場景和遞增壓力測試場景的設計，聚合報告各項參數的解析

壓力測試

  壓力測試分兩種場景：一種是單場景，壓一個接口的；第二種是混合場景，多個有關聯的接口。壓測時間，一般場景都運行10-15分鍾。如果是疲勞測試，可以壓一天或一周，根據實際情況來定。

壓測任務需求的確認

壓測前要明確壓測功能和壓測指標，一般需要確定的幾個問題：

1. 固定接口參數進行壓測還是進行接口參數隨機化壓測？
2. 要求支持多少並發數？
3. TPS（每秒鍾處理事務數）目標多少？響應時間要達到多少？
4. 壓服務器名稱還是壓服務器IP，一般都是壓測指定的服務器

壓測參數設置

　　

 

 

1. 線程數：並發數量，能跑多少量。具體說是一次存在多少用戶同時訪問
2. Rame-Up Period(in seconds):表示JMeter每隔多少秒發動並發。理解成准備時長：設置虛擬用戶數需要多長時間全部啟動。如果線程數是20，准備時長為10，那么需要10秒鍾啟動20個數量，也就是每秒鍾啟動2個線程。
3. 循環次數：這個設置不會改變並發數，可以延長並發時間。總請求數=線程數*循環次數
4. 調度器：設置壓測的啟動時間、結束時間、持續時間和啟動延遲時間。

　　（簡單的並發測試場景可以通過在線程組內的參數設置完成，例如要達到1秒並發50請求，rame_up時間為1秒，線程數設置為50）：

　　

 

　　下面有關於遞增壓力測試場景的插件介紹文檔：

　　請參考：【stepping Thread Group插件解析】https://www.cnblogs.com/fcc-123/p/10711330.html

 

壓測結果查看

  運行完后，聚合報告會顯示壓測的結果。主要觀察Samples、Average、error、Throughput。

　　

1. Samples:表示這次測試中一共發出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那么這里顯示100；
2. Average：平均響應時間——默認情況下是單個 Request 的平均響應時間（ms），當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間；
3. Error%:測試出現的錯誤請求數量百分比，即 錯誤的請求的數量/請求的總數。若出現錯誤就要看服務端的日志，配合開發查找定位原因
4. Throughput:簡稱tps,吞吐量，默認情況下表示每秒處理的請求數，也就是指服務器處理能力，tps越高說明服務器處理能力越好。

　　其他參數解析

　　(1)、Lable：Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這里顯示的就是 Name 屬性的值；

　　(2)、Median：中位數，也就是 50％ 用戶的響應時間；

　　(3)、90% Line ~ 99% Line：90％ ~99%用戶的響應時間；

　　(4)、Min：最小響應時間；

　　(5)、Maximum：最大響應時間；

　　(6)、Received KB/src：每秒從服務器端接收到的數據量；

　　(7)、Sent KB/src：每秒從客戶端發送的請求的數量。

壓測結果的分析

1. 有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的范圍內；
2. Throughput吞吐量每秒請求的數大於並發數，則可以慢慢的往上面增加；若在壓測的機器性能很好的情況下，出現吞吐量小於並發數，說明並發數不能再增加了，可以慢慢的往下減，找到最佳的並發數；
3. 壓測結束，·登陸相應的web服務器查看CPU等性能指標，進行數據的分析;
4. 最大的tps:不斷的增加並發數，加到tps達到一定值開始出現下降，那么那個值就是最大的tps。
5. 最大的並發數：最大的並發數和最大的tps是不同的概率，一般不斷增加並發數，達到一個值后，服務器出現請求超時，則可認為該值為最大的並發數。
6. 壓測過程出現性能瓶頸，若壓力機任務管理器查看到的cpu、網絡和cpu都正常，未達到90%以上，則可以說明服務器有問題，壓力機沒有問題。
7. 影響性能考慮點包括：數據庫、應用程序、中間件（tomact、Nginx）、網絡和操作系統等方面。