1. 程式人生 > >關於JMeter執行緒組中執行緒數,Ramp-Up Period,迴圈次數之間的設定概念

關於JMeter執行緒組中執行緒數,Ramp-Up Period,迴圈次數之間的設定概念

關於JMeter執行緒組中執行緒數,Ramp-Up Period,迴圈次數之間的設定概念

 

筆者是個剛剛踏入壓力測試領域不到2個月的小菜,這裡分享一下執行緒組中3個引數之間關係的個人見解,不喜請!!,望大家給出寶貴的想法。

假設:

執行緒數:n

Ramp-Up Period(有人稱之為啟動時間,有人說是準備時長,看個人喜好)

迴圈次數:a  

若每個迴圈執行時間是 t

當時間到 S = (T- T/n)時,最後一個執行緒啟動,若要使所有執行緒同時運作,則需要在最後一個執行緒啟動的時候第一個執行緒仍未關閉,為達到這個要求,需滿足 a·t > Sa > S/t

每一個個執行緒執行時間既是R = a

·t(此處的a是大於S/t的某一值),則第一個執行緒在時間點為的時候停止,整個測試理論執行時間則是 :S + R = (1-1/n)·T + a·t

總結:

測試中變數是 執行緒數 ,每個迴圈時間 是個實踐值,迴圈次數 只是為了延長單個執行緒的執行時間,從而保證當最後一個執行緒啟動時,所有執行緒都在執行中,達到壓測效果。

以上是我個人的總結,額,什麼?看不懂!其實筆者寫完了也暈了,下面我們用確切的數值進行試驗

我們設定執行緒數 n = 5,迴圈次數a = 1000,請求www.google.com,得到聚合報告如圖:

 

圖中得到谷歌首頁的平均請求時間大約為t = 0.2

這裡,我們為了方便分析,將Ramp-Up Period 

設定為T = 10秒(實際合理的時間後面會說明)

依然是n = 5,得到 S = (T- T/n) = 8 ,也就是說,從第一個執行緒啟動到第8秒的時候,最後一個執行緒開始啟動,若需要在最後一個執行緒啟動的時候第一個執行緒仍未關閉,則需要滿足 a·t > S ,已知S = 8,t = 0.2,得到 a > 40 

OK,既然迴圈次數要大於40,我們不妨把迴圈設定成100,那麼單個執行緒執行時間就是R = a·t = 20秒,也就是說第一個執行緒會在第20秒的時候停止,整個測試的理論執行時間為 S + R = (1-1/n)·T + a·t = 28

我們用一張圖來直觀的看看每個執行緒的執行情況

 

從圖中可以得到從第8秒開始,到第20秒,5個執行緒同時在執行中,此時才是真正的模擬5個使用者同時併發

說了這麼多,我們的目的到底是什麼?無非是如何設定執行緒數,Ramp-Up Period以及迴圈次數。執行緒數我就不多說了,看各個專案的測試需求,而剛剛我說了這麼多,實質上只是介紹了一些概念和如何合理的設定迴圈次數,至於Ramp-Up Period如何合理這是,請看下面大神的分析。

作為菜鳥,筆者以菜鳥的文筆和想法汙染的大家的大腦,請見諒,還是那句話,不喜請!噴!

每個執行緒均獨立執行測試計劃。因此, 執行緒組常用來模擬併發使用者訪問。假如客戶機沒有足夠的能力來模擬較重的負載,可以使用Jmeter的分散式測試功能來通過一個Jmeter控制檯來遠端控制多個Jmeter引擎完成測試。  引數 ramp-up period 用於告知JMeter 要在多長時間內建立全部的執行緒。預設值是0。假如未指定ramp-up period ,也就是說ramp-up period 為零, JMeter 將立即建立所有執行緒,假設ramp-up period 設定成T 秒, 全部執行緒數設定成N個, JMeter 將每隔T/N秒建立一個執行緒。   執行緒組的大部分引數是不言自明的,只有ramp-up period有些難以理解, 因為如何設定適當的值並不輕易。 首先,假如要使用大量執行緒的話,ramp-up period 一般不要設定成零。 因為假如設定成零,Jmeter將會在測試的開始就建立全部執行緒並立即傳送訪問請求, 這樣一來就很輕易使伺服器飽和,更重要的是會隱性地增加了負載,這就意味著伺服器將可能過載,不是因為平均訪問率高而是因為所有執行緒的第一次併發訪問而引起的不正常的初始訪問峰值,可以通過Jmeter的聚合報告監聽器看到這種現象。 這種異常不是我們需要的,因此,確定一個合理的ramp-up period 的規則就是讓初始點選率接近平均點選率。當然,也許需要執行一些測試來確定合理訪問量。   基於同樣的原因,過大的ramp-up period 也是不恰當的,因為將會降低訪問峰值的負載,換句話說,在一些執行緒還未啟動時,初期啟動的部分執行緒可能已經結束了。   那麼,如何檢驗ramp-up period I太小了或者太大了呢?首先,推測一下平均點選率並用匯流排程除點選率來計算初始的ramp-up period。 例如,假設執行緒數為100, 估計的點選率為每秒10次, 那麼估計的理想ramp-up period 就是 100/10 = 10 秒。 那麼,應怎樣來提出一個合理的估算點選率呢?沒有什麼好辦法,必須通過執行一次測試指令碼來獲得。  其次, 在測試計劃(test plan)中增加一個聚合報告監聽器,如圖2所示,其中包含了所有獨立的訪問請求(一個samplers)的平均點選率。 第一次取樣的點選率(如http請求)與ramp-up period 和執行緒數量密切相關。通過調整ramp-up period 可以使首次取樣的點選率接近平均取樣的點選率。

第三, 查驗一下Jmeter日誌(檔案位置:JMeter_Home_Directory/bin) 的最後一個執行緒開始時第一個執行緒是否真正結束了,二者的時間差是否正常。  總之,是否能確定一個適當的ramp-up time 取決於以下兩條規則:   ·第一個取樣器的點選率(hit rate)是否接近其他取樣器的平均值,從而能否避免ramp-up period 過小。  ·在最後一個執行緒啟動時,第一個執行緒是否在真正結束了,最好二者的時間要儘可能的長,以避免ramp-up period過大。  有時,這兩條規則的結論會互相沖突。 這就意味著無法找到同時滿足兩條規則的合適的ramp-up period。 糟糕的測試計劃通常會導致這些問題,這是因為在這樣的測試計劃裡,取樣器將不能充分地採集資料,可能因為測試計劃執行時間太短並且執行緒會很快的執行結束。