場景：

大家在使用Jmeter測試的時候應該發現了，

（1）執行緒啟動了就會直接傳送測試請求；--如果要模擬在一瞬間高併發量測試的時候，需要調高執行緒數量，這很耗測試機器的效能，往往無法支援較大的併發數，無法控制每次測試的瞬間併發量；

（2）如果使用了constant throughput timer，可以模擬較長時間的併發測試，但是仍無法滿足穩定的瞬間高併發測試；

解決：

1、使用集合點；

作用：阻塞執行緒，直到指定的執行緒數量到達後，再一起釋放，可以瞬間產生很大的壓力。

引用蟲師的話“紅軍排長說：等一等！集結了所有戰友後，大家再一起衝啊！這樣給敵人的壓力是最大的。”

操作步驟

1、新增集合點，在Jmeter裡是synchronized timer；

2、面板說明及設定

（1）面板說明

1）名稱：自定義名稱

2）Number of Simulated Users to Group by

 Define how many simulated users trigger the release of the synchronizing block(default value of '0'means all users).

即a.每集合夠多少個模擬使用者（執行緒）後傳送一次測試請求；

b.如果設定為0，等同於設定為執行緒租中的執行緒數；

c.確保設定的值不大於它所線上程組包含的使用者數（執行緒數）-- 一直集結執行緒而不發出測試請求，直到超時（如果設定了的話）。

例子說明：“Number of Simulated Users to Group by: 5”表示併發量是5。也就是說，Jmeter會等到5個執行緒都執行到此處時，這五個執行緒才開始執行後面的操作，先到達的執行緒將會在此等候。

3）Timeout in milliseconds

 If set to 0,no timeout will occur;if superior to 0,then if after the timeout interval the number of users waiting is not reached,timer will stop waiting.

即a.超時時間，即多少毫秒後同時釋放已集結的的執行緒，傳送測試請求；

b.如果設定為0，Timer將等待執行緒數達到了"Number of Simultaneous Users to Group"中設定的值才釋放。如果大於0，那麼如果超過Timeout in milliseconds中設定的最大等待時間(毫秒為單位)後還沒達到"Number of Simultaneous Users to Group"中設定的值，Timer將不再等待，釋放已到達的執行緒。

（2）設定

我們這裡設定Number of Simulated Users to Group by ：10

Timeout in milliseconds ：500

3、設定執行緒組屬性

因為現在是使用集合點來實現高併發測試，所以現線上程組屬性中就可以設定執行緒在較長的時間來啟動，這樣測試機器的壓力就會相對小一點；

4、新增相關請求，結果樹等，執行檢視效果

通過結果樹可以看到，請求是批量執行的；

1）開始執行的指令碼，觀察請求的增加數量趨勢；或

2）對比請求的傳送時間；

5、其他實踐

（1）實踐1--synchronizing timer應用於多個sampler中的其中一個

如果希望定時器僅應用於其中一個sampler，則把該定時器作為子節點加入，如下圖

定時器僅僅對其上的HTTP請求1起作用，即僅在HTTP請求1執行前執行定時器，和HTTP請求2無關。

（2）實踐2--synchronizing timer應用於多個sampler

如下，執行HTTP請求1和HTTP請求2前都會執行同步定時器1、2。當執行一個sampler之前時，和sampler處於相同作用域的定時器都會被執行；

注意點

1、網上部分人說“集合點的位置一定要在Sample(取樣器）之前才能生效。”

此言差矣，在Jmeter中，timer是在sampler之前執行的。不管這個定時器的位置放在sampler之後，還是之前。當然，如果有多個timer的時候，在相同作用域下，會按上下順序執行timer，這個就需要慎重放置timer的順序；

不過，為了更好的可讀性，還是建議將timer放在對應的sampler前面 或 子節點中；

2、Synchronizing timer 僅作用於同一個JVM中的執行緒。

  所以，如果使用併發測試，確保"Number of Simultaneous Users to Group by"中設定的值不大於它所線上程組包含的使用者數。

 （原文：Synchronizing timer blocks only within one JVM, so if using Distributed testing ensure you never set "Number of Simultaneous Users to Group by" to a value superior to the number of users of its containing Thread group considering 1 injector only）

試想：

a.如果分散式測試時，synchronizing timer作用於所有jvm，那麼jvm之間或者說監控jvm工作的部件就需要頻繁通訊，確定執行緒的數量及狀態等，然後集結了足夠的執行緒後，又要傳送訊號讓Jmeter來發送測試請求，中間存在延時，這樣就無法模擬更真實的高併發了，而且這個東西還會消耗測試機器的一部分效能，會給測試結果帶來負面影響；

所以暫時是隻支援控制單個jvm，如果後面有辦法解決上面那些問題後，就可以實現控制多個jvm，控制總併發量；

b.如果分散式測試，並使用了Synchronizing timer，且設定的值是小於單個jvm的執行緒數量；

但是，較難確保所有jvm都在同一時間點集結了同樣數量的執行緒數，這樣就很難下測試結論了，因為都不知道是多少併發下的效能表現；當然了，可以將執行緒的啟用時間拉長，並將超時時間延長，這樣就很可能會與同一時刻集結到足夠的執行緒，達到超高併發的測試；

所以，分散式測試與Synchronizing timer一般不是同時使用的；如果非要用，則需要慎重設定相關引數；

3、如果設定Timeout in milliseconds為0，且執行緒數量無法達到"Number of Simultaneous Users to Group by"中設定的值，那麼Test將無限等待，除非手動終止。

這個無法達到的情況有如下幾種：

a.設定的值大於執行緒數量，這樣就永遠無法達到了；

b.最後一批執行緒數不夠集合點數目；

 來源於公眾號效能測試