Jmeter之仿真高併發測試（集合點）

場景：

你們在使用Jmeter測試的時候應該發現了，

（1）線程啓動了就會直接發送測試請求；--若是要模擬在一瞬間高併發量測試的時候，須要調高線程數量，這很耗測試機器的性能，每每沒法支持較大的併發數，沒法控制每次測試的瞬間併發量；

（2）若是使用了constant throughput timer，能夠模擬較長時間的併發測試，可是仍沒法知足穩定的瞬間高併發測試；

解決：

一、使用集合點；

做用：阻塞線程，直到指定的線程數量到達後，再一塊兒釋放，能夠瞬間產生很大的壓力。

引用蟲師的話「紅軍排長說：等一等！集結了全部戰友後，你們再一塊兒衝啊！這樣給敵人的壓力是最大的。」

操做步驟

一、添加集合點，在Jmeter裏是synchronized timer；

二、面板說明及設置

（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

三、設置線程組屬性

由於如今是使用集合點來實現高併發測試，因此如今線程組屬性中就能夠設置線程在較長的時間來啓動，這樣測試機器的壓力就會相對小一點；

四、添加相關請求，結果樹等，運行查看效果

經過結果樹能夠看到，請求是批量執行的；

1）開始執行的腳本，觀察請求的增長數量趨勢；

或

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

四、其餘實踐

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

若是但願定時器僅應用於其中一個sampler，則把該定時器做爲子節點加入，以下圖

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

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

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

注意點

一、網上部分人說「集合點的位置必定要在Sample(採樣器）以前才能生效。」

此言差矣，在Jmeter中，timer是在sampler以前執行的。無論這個定時器的位置放在sampler以後，仍是以前。固然，若是有多個timer的時候，在相同做用域下，會按上下順序執行timer，這個就須要慎重放置timer的順序；

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

二、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通常不是同時使用的；若是非要用，則須要慎重設置相關參數；

三、若是設置Timeout in milliseconds爲0，且線程數量沒法達到"Number of Simultaneous Users to Group by"中設置的值，那麼Test將無限等待，除非手動終止。

這個沒法達到的狀況有以下幾種：

a.設置的值大於線程數量，這樣就永遠沒法達到了；

b.最後一批線程數不夠集合點數目；

參考鳴謝：

（1）zjq001X（十一）jmeter-集合點---學習筆記:http://blog.csdn.net/zjq001x/article/details/53107159