集合點：同一時刻去發起請求，主要應用場景是秒殺
Q：不設置集合點的測試，能代表是“並發”操作嗎？
A：有這樣一種說法，設置集合點是為了確保“嚴格意義上”的並發，其實從本質上看，這主要是一個看問題的粒度大小的問題。集合點的作用是通過工具的控制，確保一個請求嚴格地“同時”從前台提交到后台。可是如果微觀地看，是不存在嚴格意義上的並發的，即使在客戶端通過設置集合點的方式將100個請求同時提交到后台，經過網絡上的傳輸消耗，可能它們並不是同時到達的，而即便100個請求同時到達服務器端，受到中間件和應用系統、數據庫的各種連接池、緩沖區，CPU處理隊列等的限制，也可能在服務器端產生等待的。因此，嚴格意義上的“並發”可以說是不存在的，我們需要做的是在可以接受的粒度范圍內取得一個最佳的平衡點，站在這個平衡點的層面上去看待“並發”這個問題。
性能測試無非有兩個目的，一是評測，二是調優。
在以評測為目的的性能測試中，用戶更關心的是業務上的並發，也就是真實業務場景的並發情況，這種情況下只要按照業務操作的模式去設置場景就可以了，並不需要設置集合點。
集合點是一種特殊情況下的並發，通常是在以調優為目的的性能測試中才會用得到，目的是有針對性地對某個可能存在性能問題的模塊施壓，以便找到性能瓶頸。
集合點在我實際的測試過程中用得並不多。
A：有這樣一種說法，設置集合點是為了確保“嚴格意義上”的並發，其實從本質上看，這主要是一個看問題的粒度大小的問題。集合點的作用是通過工具的控制，確保一個請求嚴格地“同時”從前台提交到后台。可是如果微觀地看，是不存在嚴格意義上的並發的，即使在客戶端通過設置集合點的方式將100個請求同時提交到后台，經過網絡上的傳輸消耗，可能它們並不是同時到達的，而即便100個請求同時到達服務器端，受到中間件和應用系統、數據庫的各種連接池、緩沖區，CPU處理隊列等的限制，也可能在服務器端產生等待的。因此，嚴格意義上的“並發”可以說是不存在的，我們需要做的是在可以接受的粒度范圍內取得一個最佳的平衡點，站在這個平衡點的層面上去看待“並發”這個問題。
性能測試無非有兩個目的，一是評測，二是調優。
在以評測為目的的性能測試中，用戶更關心的是業務上的並發，也就是真實業務場景的並發情況，這種情況下只要按照業務操作的模式去設置場景就可以了，並不需要設置集合點。
集合點是一種特殊情況下的並發，通常是在以調優為目的的性能測試中才會用得到，目的是有針對性地對某個可能存在性能問題的模塊施壓，以便找到性能瓶頸。
集合點在我實際的測試過程中用得並不多。
實際業務情況對同一時間點並發要求很高（強事務要求的場景），可以設置集合點
需要模擬多個用戶恰好在同一時刻執行任務，這時候就需要創建集合點
什么是集合點
集合點可以簡單得理解為一種控制虛擬用戶行為的機制，該機制可以達到在一定時間范圍內將一定數量的虛擬用戶阻擋在一個操作行為點前的位置進行互相等待，在條件（達到虛擬用戶數量或超時）到達后喚醒全部等待中的虛擬用戶，從而達到使得一定數量的虛擬用戶可以同時進入下一個操作行為點的目的。
往往其使用初衷是為了實現最大意義上的並發來考察系統應對此種極端情況的表現。
達到增壓的目的了嗎？
集合點真的可以達到對系統增加壓力的效果嗎？
事實是不一定的（這種情況一般出現在ThinkTime和KeyTime被置0的前提下），這和你對其的使用方法和系統本身的構造息息相關，遇到的真實情況可能是在某個操作行為點上加了集合點后，整個事務性能變得更好了，這聽起來有點不可思議，但你可以嘗試分析一下原因：
（1）當用戶同時起步向前的時候，系統可以更加輕松的應對
混亂場面下的用戶可能會各自處在不同的業務操作點下，有些在查詢，有些在插入，有些在更新，這會對數據庫的事務完整性控制提出要求，數據庫會通過讀提交、可重讀或同步序列的方式，利用表級鎖、行級鎖來避免臟讀和幻讀的出現從而避免破壞ACID，在這種情況下必定會產生大量的鎖競爭，對性能會產生一定損耗。
但在用戶同步調的進行業務操作時，往往會大幅度的降低這種鎖競爭的局面，另外，這種情況下更加適合於緩存這種利器效果的發揮，這對系統來說會省下了不少力氣。
（2）集合點的出現會明顯緩解服務端所直接承受的壓力
單獨業務點上雖然看似集合后壓力增大了，但是這個要分析具體情況，首先，在釋放阻塞之前，用戶會處於互相等待的狀態中，往往會有一些表現不盡如人意的用戶拖了后腿，於是工具會陷入漫長的阻塞狀態中，對服務端的壓力逐漸減小，服務端的壓力得到明顯緩解，從而得到了喘息和休整的機會。
（3）測試工具統計結果中會加入等待時所產生的數據
用戶都在集合點互相等待會導致TPS直線下降，原因是測試工具一般會把這段時間所產生的數據也算到統計中，這就會造成在最終使用這份工具生成測試結果時的一些困擾，需要利用原始值進一步加工。
正確使用集合點
首先，不是特別建議你在測試場景的設計中加入集合點，實際上在忽略ThinkTime和KeyTime的情況下，已經可以叫並發測試了，而且效果也完全達到了預期。
如果想使用集合點，你要有十分充足的需求作為導向。另外，建議將大事務拆解為更加短小精悍的幾個小事務，並且通過分組運行調節這些事務之間的關系，比如一個組可以跑整個大事務或一些組按事務混合比跑其中幾個小事務串兒作為持續不斷的壓力背景，在這種情況下精選幾個關鍵性業務下的事務組合放入集合點，一個一個的在壓力背景環境下下運行測試，重點關注它們的真正並發表現。
一些其他用途
（1）處理業務流或數據流上下游關系
當業務流或數據流繼承關系要求耦合性非常高時，比如下游所需要處理的業務或數據必須依賴於上游所有或一定量用戶完成相應業務處理或產生數據的基礎上，可以利用集合點達到正確處理這類關系的效果。
（2）流控
當配合一些邏輯判斷腳本或工具組件時，通過判斷是否在一些特殊條件滿足的情況下啟動集合點，可以達到用戶流量控制的效果。