利托氏定理包括兩個部分：服務時間和頻率。如果我們以工具的眼光來看世界，那么我們會發現我們不能控制服務時間。但是我們確實能控制頻率。既然前面的工作說明我們進行得太快了（或者說在錯誤的方向上進行得太快了），而我們惟一能控制的就是頻率，那么我們惟一能做的就是放慢速度。我們可以通過在每兩個請求之間插入間歇來達到這個目的。這將會降低單個線程啟動請求的速度。間歇會降低線程在隊列中的時間，從而提供更符合現實的響應時間。
為了測試，我們將啟動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說明增加間歇的時間會使平均響應時間縮短。但是這條信息需要與圖4所傳達的信息相結合。在圖4中，我們可以看到，當間歇時間增加到4-7秒時不能保持要求的向服務器發出請求的速度。我們可以通過添加更多的線程來增加負載，但是這一步中存在最小值，因為這些測試的確為我們提供了有效的配置。
這一系列的測試有助于將壓力測試推進到一個更好的配置。我們的結論是：應該配置我們的測試工具，使其使用50個線程，每個線程的間歇時間為3到6秒。
結束語
在開始性能調優實踐（或者為性能確定基準）之前，需要確認工具不會影響測試。配置良好的工具不會讓我們測量不該測量的數據。不能交付適當的負載或會使我們測量偶然的響應時間的測試工具將會影響對應用程序進行性能調優的工作。要想知道是否發生了這種情況，關鍵是要度量工具以正常速度運行的效果。這種效果可以由工具滿足或支持所要求的每秒的事務或請求數目的能力來確定。工具不應該立刻輪換線程（來發出下一個請求）。如果發生了這種情況，就需要降低工具的速度，以免人為地使服務器的容量溢出。通常需要試驗幾次以達到測試工具的適當的平衡配置。在測試的早期階段，不要把重點放在響應時間（它會隨著對應用程序調優的過程而改善）上，而是要放在配置好工具上。最后，不要害怕放慢速度，因為這樣做可能有助于弄清楚到底是什么影響了應用程序的性能。
| 作者簡介 | |
| Kirk Pepperdine是JavaPerformanceTuning.com的首席技術官(CTO)，最近15年來他一直專心研究對象技術和性能調優。Kirk是《ANT Developer's Handbook》(SAMS出版社)一書的作者之一�？梢酝ㄟ^kirk@JavaPerformanceTuning.com聯系Kirk。 | |
文章來源于領測軟件測試網 http://www.kjueaiud.com/
