的方案對我們來說通常是不可行的，因為我們很有可能要受到可用的硬件數目和/或許可證數目（對于商業的負載測試工具來說）的限制。解決方法其實很常見，就是我們需要達到一種維持合適的請求間時間間隔與使用過多的（計算/許可）資源之間的平衡。我們要始終記住，如果測試工具使用的資源（不管是硬件、軟件或是線程）很少，就會影響我們測試的有效性。
三思而后行
我們使用Apache JMeter來對隨機的Web應用程序進行負載測試，以說明壓力測試工具是如何影響測試結果的。除了要知道應用程序的入口點是Servlet，應用程序的功能以及如何實現的詳細信息對于我們的討論來說并不重要。
圖1顯示了在平均響應時間下增加線程數目的效果。其中粉紅色的線是沒有調整線程的情況。藍色的線是在每兩個線程之間添加了500ms的空余時間后的線程。從圖中可以看出，兩種情況的結果差別非常小。每種情況都清楚表明，隨著系統的負載增加，響應時間也會增加。既然我們已經知道服務器的性能會隨總體負載的增加而降低，這樣的結果也就不奇怪了。我們只是在看圖2所示的結果時才能看出存在的問題。
圖2顯示維持穩定的請求速度的能力最初是受制于線程數目的。同樣這也不能說明問題，因為有理由假定，在超出特定的線程數目閾值之前，不能維持合理的服務器負載。圖2也顯示，一旦超出了服務器處理請求的能力，線程的增加對工具向服務器發出請求的整體速度的影響就不明顯了。另外一點是，這些“額外” 的線程所造成的響應時間的增加確實暗示它們影響了系統的負載。
問題在于：為什么不增加服務器負載的線程看起來會降低服務器的性能？一個可能的答案就是，并不是線程降低了服務器的性能，而是服務器一結束對線程的服務，線程就被排隊了。因為測量響應時間的計時器必須在將請求發送給服務器時啟動，在收到響應時停止，所以響應時間必然包括線程在隊列中等待服務的所有時間，再加上服務時間。因為線程一離開就進入系統，就造成了這樣的情況：線程必須等待其他每個線程完成后才能被服務。在這種場景下，線程越多就會造成隊列和響應時間越長。
利托氏定理告訴我們，這種系統是發散的，而由此可以得出結論：工具妨礙了確定真正的瓶頸（如果存在的話）的能力。
放慢速度，做得更多
文章來源于領測軟件測試網 http://www.kjueaiud.com/
