我有一個運行 2 小時的簡單壓力測驗場景。我已經配置了 3000 個執行緒，以便在整個測驗期間增加。這只是一個 HTTPS POST 請求重復多次，并更改每個請求的 json 正文資料。客戶端在一個系統上，而服務器在另一個系統上。我只是用一些輸入資料呼叫 API，該 API 在檔案中查找資料，并用硬編碼來回應的任何內容進行回應。
怎么可能雖然我隨著時間的推移不斷增加執行緒數，但系統上的負載卻沒有成比例地增加？
我問這個是因為幾天前在做這個測驗時，平均回應時間隨著我的執行緒（虛擬用戶）的增加成比例增加。現在，在進行相同的測驗時，這種增加不再發生 - 這就是為什么現在我猜測開發人員已經設定了一些最大 TPS 限制。
這是回應時間隨時間的結果：
這是總 TPS：
隨著時間的推移活動執行緒結果：
隨著時間的推移位元組吞吐量：
有人可以幫我理解這是怎么可能的嗎？沒有錯誤代碼。
似乎服務器以某種方式限制了客戶端，但我不明白通過哪種機制，也不知道哪個 jmeter 結果圖會向我顯示更清晰的證據。如果有人能幫助我理解，我將不勝感激。
uj5u.com熱心網友回復：
您正在顯示來自不同測驗執行的結果，因此我們無法正確關聯它們，即回應時間從 開始，23:15而其他 2 個圖表以 結束23:01。
一般來說，行為良好的系統的吞吐量應該與增加的負載成比例地增加。如果它沒有發生 - 應該對此有一個解釋，即
- 回應時間增加，嘗試查看
22:23和之間的持續時間的回應時間23:01 - JMeter 發送請求的速度不夠快，請確保遵循 JMeter 最佳實踐并使用JMeter PerfMon 插件監控您的負載生成器資源，如 CPU、RAM 等
- 由于配置或實作限制，應用程式回應速度不夠快，請使用APM或Profiler工具檢查 API 呼叫背后發生的情況
- JMeter 不報告錯誤的事實并不一定意味著沒有錯誤，您的應用程式可能會以HTTP 狀態代碼 200回應，但正文包含錯誤詳細資訊，因此查看 ie Bytes Throughput Over Time chart是有意義的查看傳輸的資料量是否隨著用戶的到達而增長。您還可以考慮將斷言添加到您的請求中，以確保您的測驗正在做它應該做的事情
uj5u.com熱心網友回復：
該問題可能是由客戶端限制實際執行的執行緒數引起的。換句話說，執行緒可能在負載生成器處排隊。有關詳細說明，請參閱 Dr. Gunter如何獲得令人難以置信的負載測驗結果，特別是4.4 Threads That Throttle部分。該論文展示了一種使用利特爾定律來估計實際執行執行緒數的方法。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/339131.html