提到的，在發散系統中，每個后繼用戶的響應時間都要比前一個所經歷的時間長。這意味著平均響應時間將不斷地增長而沒有限制。盡管如此，但是我們人為地限制了客戶端的數目，因此平均響應時間將穩定在一個點上，該點取決于客戶端數目與處理單個請求所花費時間的乘積。這里所說的這種系統中的響應時間包括花在隊列中的時間，而且因為花在隊列中的時間比預料的要少，所以我們又人為擴大了測量值。最終結果是您的測試限制了您確定系統的可伸縮性的能力。
如何修復
要修復壓力測試，需要知道用戶/線程發出請求的速度。所有用戶的速度之和就轉化為服務器接受請求的速度。一旦確定了這個值，就可以對工具發出請求的速度進行調整。下面的表列出了幾個可以用來維持50個請求每秒(RPS)的值。從服務器的視角來看，工具需要每20ms提供一個請求。這種觀點反映的是單個線程的情況。如果工具配置了兩個線程，那么對于每個線程，都應該維持40ms的請求間時間間隔。表中還列出了使用5個線程和10個線程的情況下的時間間隔。
|
線程數目 |
線程頻率 |
請求間時間間隔(inter-request interval) |
|
1 |
50/sec |
20ms |
|
2 |
25/sec |
40ms |
|
5 |
10/sec |
100ms |
|
10 |
5/sec |
200ms |
抉擇
從理論上來說，這個表展示了如何使用1個、2個、5個、10個線程來實現所要求的維持50個RPS的目標。但是如果服務時間比請求間時間間隔長的話會怎么樣呢？這種情況下駐留在服務器中的線程不能使下一個請求排入隊列，工具也不能交付50RPS的預期負載。為了避免這種情況發生，需要在系統中構建一些空余時間(slack)。使用大量線程
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
