1、集合點介紹
“性能測試”一般思路是“多用戶並發測試”，但真正的並發其實是不存在的，為了更真實、更接近的實現並發，在需要壓力的地方設置集合點，等所有用戶都到位的時候，然后一起訪問，從而實現並發。
舉個例子，要測試100個用戶同時登錄，每到輸入用戶名和密碼登錄的地方，所有的虛擬用戶都相互等待，等100個用戶都輸入完畢，相當於集結在一起了 ，然后再一起訪問。
（1）集合點含義
集合點可以簡單得理解為一種控制虛擬用戶行為的機制，該機制可以達到效果是：在一定時間范圍內，將一定數量的虛擬用戶，阻擋在一個操作行為點前的位置，進行互相等待。在條件（達到虛擬用戶數量或超時）到達后，喚醒全部等待中的虛擬用戶。從而達到，使一定數量的虛擬用戶，可以同時進入下一個操作行為點的目的。
（2）集合點作用
讓所有請求在不滿足條件的時候處於等待狀態，等待滿足條件后，再同時一起發起請求。也就是模擬讓所有用戶，恰好在同一時刻執行任務，進行同步並發。常用在並發測試或壓力測試中。
在實際工作中，往往初衷是為了實現最大意義上的並發，來考察系統應對此種極端情況的表現。
常見應用場景：秒殺。
提示：實現集合點的組件為同步定時器。
2、同步定時器界面介紹
Synchronizing Timer組件翻譯過來叫同步定時器。
添加同步定時器組件方式：選中“取樣器”右鍵 —> 添加 —> 定時器 —> Synchronizing Timer。
界面內容如下圖所示：
同步定時器界面詳細說明：
- 名稱：同步定時器組件的自定義名稱，見名知意最好。
- 注釋：即添加一些備注信息，對該同步定時器組件的簡短說明，以便后期回顧時查看。
- 模擬用戶組的數量（
Number of Simulated Users to Group by）：一次集合多少用戶后再執行請求。也就是設置模擬並發請求的線程數。
如果設置為0，默認等於線程組元件中設置的線程數。 - 超時時間以毫秒為單位（
Timeout in milliseconds）：集合這些用戶所花費的時間。
1）設置為0，無限等待，直到達到集合點設置的線程數。
2）設置指定時長，如果到達指定時長，集合點數量未到達，這時該集合中有多少用戶，就釋放多少用戶數量。
提示：
- 如果設置
Timeout in milliseconds為0，且線程數量無法達到Number of Simultaneous Users to Group by中設置的值，那么測試將無限等待，除非手動終止。（可能會導致程序掛起） - 同步定時器組件僅作用於同一個線程組，所以如果使用並發測試，確保
Number of Simultaneous Users to Group by中設置的值，不大於它所在線程組設定的用戶數。（集合數最好能被線程組中設置的線程數整除） - 集合時間最好大於等於線程組中的啟動時間。當集合線程數不能被線程組的線程數整除時，集合時間不要設置為0。
- 作用域：當執行一個
Sampler之前時，和Sampler處於相同作用域的定時器都會被執行。如果希望定時器僅應用於其中一個Sampler，則把該定時器作為子節點加入。
3、集合點的使用
例如：現在有一個需求，實現批量用戶進行部門查詢操作。
（1）測試計划內包含的元件
添加元件操作步驟：
- 創建測試計划
- 創建線程組：
選中“測試計划”右鍵 —> 添加 —> 線程（用戶） —> 線程組。 - 在線程組中，添加取樣器”HTTP請求“組件：
選中“線程組”右鍵 —> 添加 —> 取樣器 —> HTTP請求。 - 在取樣器中，添加定時器
Synchronizing Timer組件：選中“取樣器”右鍵 —> 添加 —> 前置處理器 —>Synchronizing Timer。 - 在線程組中，添加監聽器察看結果樹組件：
選中“線程組”右鍵 —> 添加 —> 監聽器 —> 察看結果樹。
最終測試計划中的元件如下：
點擊運行按鈕，會提示你先保存該腳本，腳本保存完成后會直接自動運行該腳本。
（2）線程組元件內容
設置該線程組的線程數為50，來模擬50個用戶進行數據的查詢。
下圖中的設置為，在1秒內啟動50個線程。
（3）HTTP請求組件內容
一個查詢請求的基本編輯，如下圖所示：
（4）同步定時器內容
我們設置同步定時器為：
- 集合數為50：和線程組設定的線程數相同。
- 集合等待時間設置為3秒：集合等待時間大於線程組中所有線程的啟動時間。
界面內容如下：
（5）運行腳本查看結果
下圖為腳本的運行結果，這樣看沒有什么意義，一般要配合聚合報告組件查看。
提示：聚合報告內容下一篇文章詳細說明。
4、集合點設置情況說明
- 場景一：
線程數設置為10，集合點為5，超時為0。
會看到有10個結果，此處分成了2組進行並發，每次是5個用戶。 - 場景二：
線程數設置3，集合點設置為4，超時為0。
發現沒有執行請求，需要手動stop腳本的運行。原因：不夠並發數且超時設置為0。 - 場景三：
線程數設置6，集合點設置為4，超時為0。
發現只有4個請求，然后一直都沒有停止，需要手動stop腳本的運行。原因：第一組夠集合點，一起並發，第二組只有2個，不夠集合點，且設置超時為0。 - 場景四：
線程數設置6，集合點設置為6，超時為0。
可以看到有6個請求。分1組執行。 - 場景五：
線程數設置6，集合點設置為4，超時為5000，點擊運行。
分2組執行，發現先有4個請求，為第一組，5秒后，出現后2個請求，為第二組，共6個。
5、集合點總結
集合點最關鍵的就是策略問題，涉及到兩個方面：
- 同步並發時機問題：即什么時候同步並發？
- 超時問題：比如目的是達到100個用戶時，才向服務器發請求，而這個過程中存在一個超時問題，可能是從第50個並發到第100個並發之間超時了，超時怎么處理？
正確使用集合點：
首先，測試場景的設計中加入集合點，實際上是在忽略ThinkTime（思考時間）和KeyTime的情況下，已經可以叫並發測試了，而且效果也完全達到了預期。
另外，建議將大事務拆解為更加短小精悍的幾個小事務，並且通過分組運行調節這些事務之間的關系，比如一個組可以跑整個大事務，或者一些組按大小事務混合跑。在這種情況下精選幾個關鍵性業務的事務組合，並放入集合點。然后一個一個的在壓力背景環境下運行測試，重點關注它們的真正並發表現。
參考：