如何調整壓力測試工具[2]

　　如何調整壓力測試工具[2]   壓力測試工具

　　如何修復

　　要修復壓力測試，需要知道用戶/線程發出請求的速度。所有用戶的速度之和就轉化為服務器接受請求的速度。一旦確定了這個值，就可以對工具發出請求的速度進行調整。下面的表列出了幾個可以用來維持50個請求每秒(RPS)的值。從服務器的視角來看，工具需要每20ms提供一個請求。這種觀點反映的是單個線程的情況。如果工具配置了兩個線程，那么對于每個線程，都應該維持40ms的請求間時間間隔。表中還列出了使用5個線程和10個線程的情況下的時間間隔。

　　抉擇

　　從理論上來說，這個表展示了如何使用1個、2個、5個、10個線程來實現所要求的維持50個RPS的目標。但是如果服務時間比請求間時間間隔長的話會怎么樣呢?這種情況下駐留在服務器中的線程不能使下一個請求排入隊列，工具也不能交付50RPS的預期負載。為了避免這種情況發生，需要在系統中構建一些空余時間(slack)。使用大量線程的方案對我們來說通常是不可行的，因為我們很有可能要受到可用的硬件數目和/或許可證數目(對于商業的負載測試工具來說)的限制。解決方法其實很常見，就是我們需要達到一種維持合適的請求間時間間隔與使用過多的(計算/許可)資源之間的平衡。我們要始終記住，如果測試工具使用的資源(不管是硬件、軟件或是線程)很少，就會影響我們測試的有效性。

　　三思而后行 軟件測試

　　我們使用Apache JMeter來對隨機的Web應用程序進行負載測試，以說明壓力測試工具是如何影響測試結果的。除了要知道應用程序的入口點是Servlet，應用程序的功能以及如何實現的詳細信息對于我們的討論來說并不重要。

　　圖1顯示了在平均響應時間下增加線程數目的效果。其中粉紅色的線是沒有調整線程的情況。藍色的線是在每兩個線程之間添加了500ms的空余時間后的線程。從圖中可以看出，兩種情況的結果差別非常小。每種情況都清楚表明，隨著系統的負載增加，響應時間也會增加。既然我們已經知道服務器的性能會隨總體負載的增加而降低，這樣的結果也就不奇怪了。我們只是在看圖2所示的結果時才能看出存在的問題。

　　圖1

　　圖2顯示維持穩定的請求速度的能力最初是受制于線程數目的。同樣這也不能說明問題，因為有理由假定，在超出特定的線程數目閾值之前，不能維持合理的服務器負載。圖2也顯示，一旦超出了服務器處理請求的能力，線程的增加對工具向服務器發出請求的整體速度的影響就不明顯了。另外一點是，這些“額外”的線程所造成的響應時間的增加確實暗示它們影響了系統的負載。

　　圖2

原文轉自：http://www.kjueaiud.com