深度剖析階梯負載與最終請求數

概述

最近有不少朋友來諮詢關於階梯加壓與聚合報告中實際請求數的問題。服務器

你們的困惑基本一致,那就是明明本身只設置了幾十個線程,最後爲何聚合報告中跑出了上萬個請求?spa

關於這個問題,今天來實際操做並記錄一下,解答你們的疑惑。線程

實驗

仍是用百度作例子blog

咱們設置階梯加壓線程組的請求參數,以下圖資源

 

 

此圖表示

1:每隔2秒鐘,會在1秒內啓動5個線程百度

2:每次線程加載以後都會運行2s而後開始下一次線程加載請求

3:最終會加載50個線程並持續運行30sim

4:50個線程持續運行30s後,會每隔2秒鐘中止5個線程,剩餘的線程繼續負載。一直到全部線程徹底中止d3

 

要正確理解最終請求數是如何計算出來的。咱們必須知道每一秒鐘線程到底釋放了多少請求!!數據

 

階梯加壓階段:

若是該請求的平均響應時間是100ms,那麼一秒內就能夠迭代10

那麼,這1秒內我若是啓動了5個線程,那麼這1s內發出的請求數就是5*10=50次

接着,它運行了2s鍾纔開始加載下一波線程。在這2秒以內,它發出的請求數是2*5*10=100

在2s以後,線程組又在1s內釋放了5個請求,並運行了2s。那麼在這2s內,它發出的請求是2*10*10=200次(此時是10個線程在運行)

以此類推,一直到50個線程加載完以前,咱們的線程組釋放的請求數是這樣的

(2*5*10)+(2*10*10)+(2*15*10)+(2*20*10)+(2*25*10)+....+(2*45*10)=4500

 

持續負載階段:

注意:爲何最後不是2*50*10呢?由於從50個線程加載完以後,咱們進行的是30s的持續負載!!

這30s內,咱們的總的請求數是30*50*10=15000

 

線程釋放階段:

在30s負載結束以後,咱們的線程組開始階梯式釋放

此時,即便是線程組在釋放,那麼剩餘的線程依然在發起請求

(2*45*10)+(2*40*10)+(2*35*10)+(2*30*10)+(2*25*10)+....+(2*5*10)=4500次

 

總的請求數=4500+15000+4500=24000次

 

是否是請求數真的就這麼精確呢?其實這樣計算也是不許確的

由於隨着咱們的負載愈來愈大,對服務器資源的消耗也愈來愈大,請求的響應時間也會愈來愈長

響應時間愈來愈長,那麼相應的每秒迭代次數就會變少。咱們這裏的響應時間僅僅取了個平均值,真實的數據確定會有偏差

相關文章
相關標籤/搜索