圖2顯示維持穩定的請求速度的能力最初是受制于線程數目的。同樣這也不能說明問題，因為有理由假定，在超出特定的線程數目閾值之前，不能維持合理的服務器負載。圖2也顯示，一旦超出了服務器處理請求的能力，線程的增加對工具向服務器發出請求的整體速度的影響就不明顯了。另外一點是，這些“額外”的線程所造成的響應時間的增加確實暗示它們影響了系統的負載。
圖2
問題在于：為什么不增加服務器負載的線程看起來會降低服務器的性能?一個可能的答案就是，并不是線程降低了服務器的性能，而是服務器一結束對線程的服務，線程就被排隊了。因為測量響應時間的計時器必須在將請求發送給服務器時啟動，在收到響應時停止，所以響應時間必然包括線程在隊列中等待服務的所有時間，再加上服務時間。因為線程一離開就進入系統，就造成了這樣的情況：線程必須等待其他每個線程完成后才能被服務。在這種場景下，線程越多就會造成隊列和響應時間越長。
利托氏定理告訴我們，這種系統是發散的，而由此可以得出結論：工具妨礙了確定真正的瓶頸(如果存在的話)的能力。
放慢速度，做得更多
利托氏定理包括兩個部分：服務時間和頻率。如果我們以工具的眼光來看世界，那么我們會發現我們不能控制服務時間。但是我們確實能控制頻率。既然前面的工作說明我們進行得太快了(或者說在錯誤的方向上進行得太快了)，而我們惟一能控制的就是頻率，那么我們惟一能做的就是放慢速度。我們可以通過在每兩個請求之間插入間歇來達到這個目的。這將會降低單個線程啟動請求的速度。間歇會降低線程在隊列中的時間，從而提供更符合現實的響應時間。
為了測試，我們將啟動50個經過調整的每秒產生9個請求的線程。如果我們發現不能維持合理的請求速度，這些值還可以調整。使用響應時間來評價效果。最后要設置的是間歇時間�？梢允褂糜上惹斑\行得出的數據來幫助我們做出決定。
回到圖1，我們可以看到，8到9個RPS會產生2到3秒的響應時間。利托氏定理告訴我們，我們需要足夠的線程，以便在2到3秒的時間幀后就可以自由進入系統(假定可以提高平均響應時間)。因此平均的間歇時間大約是3秒。為了練習，我們將運行一系列的測試來探討值的范圍。
第一次測試使用2到2.5秒之間的一個隨機選取的值。這個范圍的值的平均間歇時間是3.5秒�？梢岳眠@條信息計算請求的理論速度：用50(線程數目)除以3.5+2(目標響應時間的估測值)。得到的值是9.1RPS。第二次測試使用3到6秒之間的一個隨機值。最終測試使用4到6之間的值。這些測試的結果如圖3所示。
圖3
文章來源于領測軟件測試網 http://www.kjueaiud.com/
