使用JMeter查找應用程序的可伸縮性點

我正在嘗試使用JMeter來查找應用程序的可伸縮性點。我將可擴展性定義爲「任何增加不再增加吞吐量的最小併發用戶數」。使用JMeter查找應用程序的可伸縮性點

我正在使用以下技術。安排我的負載測試運行一個小時，啓動一個每30秒發送一次SOAP/XML-RPC請求的新線程。我通過將線程數設置爲120，並將加速期設置爲3600秒來完成此操作。

然後在我的總結報告監聽器中查看我的TOTAL行吞吐量。每隔30秒添加一個新行（線程），總吞吐量數量將上升，直到80個線程在我的情況下處於活動狀態後，每秒大約123個請求達到穩定狀態。隨着最後20個線程的添加，它會慢慢將吞吐量數降至每秒120個。然後我得出結論：我的應用程序可伸縮性點數爲80個活動用戶每秒123個請求。

我的問題是，這是一種有效的方法來找到一個應用程序的可擴展性點還是有不同的技術，我應該嘗試？

來源

2014-01-10 Mike

從技術角度而言，您正在做的是回答您關於某個特定用戶場景的問題，但我認爲您可能錯過了大局。

首先請記住，您發送的實際HTTP請求和上升時間通常會影響您稱之爲可擴展性的點。您的請求是否打到緩存？他們不夠隨機？他們太隨意了嗎？他們代表真實世界的請求嗎？ 30秒會給你20秒還是10秒的結果？

從我個人的經驗來看，當試圖分析應用程序性能時，查看圖很容易，也更直觀。這不僅是一個原始數據的問題，而且還包括外觀和趨勢以及變化率。

例如，以下是使用JMeter和交互式JMeter結果圖測試ghost.org博客平臺的示例。
http://blazemeter.com/blog/ghost-performance-benchmark

來源

2014-01-10 18:30:52

我已經執行了其他負載測試，它反映了API和其他重負載測試的實際使用情況，涵蓋了我所有的請求類型。我正在測試的API有8種不同類型的請求和響應。對於此測試，我選擇了一個一致返回最大大小的XML響應數據的請求。我將結果保存到CSV JTL文件，我已將圖應用到JTL文件（如響應時間圖）。我同意我在測試運行時以非常規方式使用加速期來添加用戶。 – Mike

回答您的一些問題：我的請求沒有達到緩存。對於這種類型的測試，我不認爲我需要隨機請求，因爲我只是想確定當用戶緩慢添加時，我的服務器可以產生的最大吞吐量。更改加速期以便每10或20秒添加一個新用戶不應影響結果，除非我在結果中更快地達到最大吞吐量（我應該可能會測試此內容，但需要進行確認）。其他人對這種找到可擴展性點的技巧有任何想法嗎？ – Mike

我也確保使用一些應用程序性能監視解決方案，如New Relic。雖然JMeter將提供端到端的負載和響應時間，但看到後端性能KPI非常有價值。 –

使用JMeter查找應用程序的可伸縮性點

回答

相關問題