摘自:併發
http://blog.csdn.net/richnaly/article/details/7967364函數
集合點的意思時等到特定的用戶數後再一塊兒執行某個操做,好比一塊兒保存,一塊兒提交(咱們一般意義上的併發數並非指一塊兒提交或者一塊兒保存),通常狀況下使用不到集合點,不過,訂票系統或者促銷類須要用到,好比說某個促銷品的促銷時間在8點到8點30,這樣的話,就可能出如今8點時不少人一塊兒提交的場景
集合點函數能夠幫助咱們生成有效可控的併發操做。雖然在Controller中多用戶負載的Vuser是一塊兒開始運行腳本的,可是因爲計算機的串行處理機制,腳本的運行隨着時間的推移,並不能徹底達到同步。這個時候須要手工的方式讓用戶在同一時間點上進行操做來測試系統併發處理的能力,而集合點函數就能實現這個功能。集合點只須要在腳本中插入lr_rendezvous()函數便可。打開Insert菜單下的Rendezvous選項,如圖3.167所示。測試
在彈出的對話框中輸入集合點名稱run,肯定後便可獲得對應的腳本:spa
引號內的就是集合點名稱,當腳本在多用戶運行的狀況下,每次運行到這個函數都會查看一下集合點的策略來決定是等待仍是繼續運行。集合點的設置內容存放在場景的設置中,當腳本中有集合點函數時,場景中的集合點設置功能就能夠訪問,如圖3.168所示。.net
圖3.167 添加集合點函數 |
圖3.168 場景中的集合點設置 |
打開場景菜單下的集合點後,能夠爲集合點進行設置,包括哪些用戶使用該集合點、集合點是否有效等,如圖3.169所示。xml
若是腳本中沒有集合點,那麼場景中的Scenario/Rendezvous集合點功能將會是灰色顯示。blog
集合點策略用來設置虛擬用戶集合的方式,打開Policy對話框,如圖3.170所示。事務
集合點提供瞭如下3種策略:內存
1.當百分之多少的用戶到達集合點時腳本繼續。ci
2.當百分之多少的運行用戶到達集合點時腳本繼續。
(點擊查看大圖)圖3.169 場景中的集合點設置窗口 |
(點擊查看大圖)圖3.170 場景中的集合點策略 |
3.多少個用戶到達集合點時腳本繼續。
這3個策略的區別在於:假設腳本由100個用戶來運行,但100個用戶並非一開始就共同運行的。假設每隔1分鐘添加10個用戶,也就是說10分鐘後系統纔有100個在線用戶。這裏100就是指系統訪問的全部用戶數,而不一樣時間的在線用戶數是不一樣的。設置的集合點策略百分比均爲100%。
在場景運行時,當Vuser腳本運行到集合點函數時,該虛擬用戶會進入集合點狀態直到集合點策略知足後才釋放。
策略1是指當所有用戶都運行到了集合點函數才釋放集合,讓這100個用戶併發運行後面的腳本。
策略2是指當前時間若是隻有10個用戶在線,那麼只須要這10個用戶都運行到了集合點函數就釋放集合,讓這10個用戶併發運行後面的腳本。
策略3就比較好理解了,當到達集合點的用戶數達到本身設置的數量後就釋放等待,併發運行後面的腳本。
能夠在多個腳本上設置相同的集合點名稱來實現多個腳本同時併發的效果。
集合點超時
在腳本運行時,每一個虛擬用戶到達集合點時都會去檢查一下集合點的策略設置,若是不知足,那麼就在集合狀態等待,直到集合點策略知足後,才運行下一步操做。可是可能存在前一個虛擬用戶和後一個虛擬用戶達到集合點的時間間隔很是長的狀況,因此須要指定一個超時的時間,若是超過這個時間就不等待遲到的虛擬用戶了。
超時時間是指虛擬用戶之間的時間差,當出現兩個虛擬用戶到達集合點的時間差超過設定的超時時間時,全部在集合點處於等待狀態中的用戶將所有釋放。
集合點和事務
集合點應該放在事務外,若是事務內存在集合點,那麼虛擬用戶在集合點等待的過程也會被算入事務時間,致使早進入集合點的用戶的響應時間有誤。
常見的田徑比賽就是這樣,你們先集合在同一塊兒跑線上,鳴槍後開始計時,達到終點再計時,這樣就能獲得準確的事務時間。