如何調整壓力測試工具(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.uml.org.cn/Test/200808077.asp