每個人都可以參與
如果我們讓模擬線程盡可能快地發出請求，就是在模擬整個全域(甚至更多)的用戶都在同一時間發出請求。我們假定服務器模型為單一的，因為這樣便于理解;多服務器模型的工作方式是相同的，只是更快一些。系統將把請求排隊，并且每次只處理一個。一旦有一個請求清除，線程會立即返回隊列頭部發出下一個請求。雖然這種事件順序似乎說明我們處理的是一個穩定狀態的系統，但我們實際上是在處理發散系統。它之所以看起來像穩定狀態系統的惟一原因是，我們限制了發出請求的線程數目。正如前面所提到的，在發散系統中，每個后繼用戶的響應時間都要比前一個所經歷的時間長。這意味著平均響應時間將不斷地增長而沒有限制。盡管如此，但是我們人為地限制了客戶端的數目，因此平均響應時間將穩定在一個點上，該點取決于客戶端數目與處理單個請求所花費時間的乘積。這里所說的這種系統中的響應時間包括花在隊列中的時間，而且因為花在隊列中的時間比預料的要少，所以我們又人為擴大了測量值。最終結果是您的測試限制了您確定系統的可伸縮性的能力。
如何修復
要修復壓力測試，需要知道用戶/線程發出請求的速度。所有用戶的速度之和就轉化為服務器接受請求的速度。一旦確定了這個值，就可以對工具發出請求的速度進行調整。下面的表列出了幾個可以用來維持50個請求每秒(RPS)的值。從服務器的視角來看，工具需要每20ms提供一個請求。這種觀點反映的是單個線程的情況。如果工具配置了兩個線程，那么對于每個線程，都應該維持40ms的請求間時間間隔。表中還列出了使用5個線程和10個線程的情況下的時間間隔。
抉擇
從理論上來說，這個表展示了如何使用1個、2個、5個、10個線程來實現所要求的維持50個RPS的目標。但是如果服務時間比請求間時間間隔長的話會怎么樣呢?這種情況下駐留在服務器中的線程不能使下一個請求排入隊列，工具也不能交付50RPS的預期負載。為了避免這種情況發生，需要在系統中構建一些空余時間(slack)。使用大量線程的方案對我們來說通常是不可行的，因為我們很有可能要受到可用的硬件數目和/或許可證數目(對于商業的負載測試工具來說)的限制。解決方法其實很常見，就是我們需要達到一種維持合適的請求間時間間隔與使用過多的(計算/許可)資源之間的平衡。我們要始終記住，如果測試工具使用的資源(不管是硬件、軟件或是線程)很少，就會影響我們測試的有效性。
三思而后行
我們使用Apache JMeter來對隨機的Web應用程序進行負載測試，以說明壓力測試工具是如何影響測試結果的。除了要知道應用程序的入口點是Servlet，應用程序的功能以及如何實現的詳細信息對于我們的討論來說并不重要。
圖1顯示了在平均響應時間下增加線程數目的效果。其中粉紅色的線是沒有調整線程的情況。藍色的線是在每兩個線程之間添加了500ms的空余時間后的線程。從圖中可以看出，兩種情況的結果差別非常小。每種情況都清楚表明，隨著系統的負載增加，響應時間也會增加。既然我們已經知道服務器的性能會隨總體負載的增加而降低，這樣的結果也就不奇怪了。我們只是在看圖2所示的結果時才能看出存在的問題。
圖1
文章來源于領測軟件測試網 http://www.kjueaiud.com/
