近來跟蹤一個項目，發現同事們在執行性能測試時，比較熱衷於使用集合點，從概念上認爲要得到併發用戶就必須設置集合點，認爲在執行一個壓力測試腳本時，設置了集合點纔算是有效的併發用戶，沒有設置結合點，就認爲可能這個就不能準確的代表併發用戶數。當前我並反對這個觀點，不過卻讓我有一種疑慮，促使我想更深入的理解併發用戶和集合點，我相信大多數進入性能測試研究領域的朋友都應該有疑惑，主要原因我覺得還是由於不能深入理解LoadRunner的實現原理，而且缺乏對系統整個過程的分析，其中這裏面涉及到的知識包括網絡、協議、中間件、數據庫、應用層以及緩衝區和緩存等等，當然還與硬件資源CPU隊列和內存等有着千絲萬縷的聯繫。所以說要成爲一個優秀的性能測試人員，真還不一個容易的過程，是需要長時間積累和學習的，只有通過大量的項目實踐和分析，最後再總結于思想，纔有可能成爲這個領域的專家，當然也希望真正想把性能測試做好的朋友都能爲此將不懈努力，樂於分享和討論。
先來看一個應用系統的結構圖，如下所示：
這個圖源於小布老師的視頻中，比較直觀、簡潔地反映了一個應用系統的運行過程，其中包括客戶端、網絡、應用服務器和數據庫服務器，其中每一個環節都是在執行性能測試分析中必不可少的元素，結構圖中也合理得分析出了響應時間的處理過程，當請求從客戶端發出之後到最後返回到客戶端，這個過程中每一個環節的處理都有可能最後成爲系統運行中的性能瓶頸，所以可見對系統整體結構的理解是何等重要。
接下來我們來看看關於併發用戶和集合點的定義：
併發用戶：通俗意義上講就是同時操作的用戶，當然這個“同時”可以理解爲同一時間段，還可以理解爲同一時間點，當然如果說併發就是同一時間點上同時操作的用戶，這樣理解沒有錯誤，但對於實際情況來講，是沒有嚴格意義上的併發執行的，就如同進程和線程關係一樣，在某一個點嚴格上講就只有一個人得到執行的權利。
集合點：用以同步虛擬用戶，以便恰好在同一時刻執行任務。這個從概念上來講，其實也是比較模糊，正因爲模糊，使用才值得去深入探討。對於LoadRunner來說，集合點只是一種策略，而這個策略也會有很多規則，因爲實際情況中並非所有用戶都會同時到達集合點，上面的那個結構圖就能解釋這個誤解，因爲從客戶端發出到網絡、中間件、應用層再到數據庫，這其中的每一個環節都有延時，也就是說不可能所有的用戶都能到達所謂的集合點，纔開始同時執行操作。
從上面的兩個概念的理解來講，有人就會思考，併發用戶和集合點到底有沒有關係，這纔是關鍵。當然這個就要看需求是什麼了，所以說很多時候我們誤用集合點和併發用戶，其實根本原因在於對需求的理解，需求本身都沒有搞清楚他想實現的場景，得到什麼樣的結果。當然，我們只能感慨需求並是專業的技術人員，至少我們大多數人碰到的需求都不一定是技術出身，所以他們不明白，我們就不能裝忽悠，不然結果就肯定不符合實際了。
通常情況下，我們會得到用戶這樣的需求“本系統要達到併發用戶200”，這種需求從嚴格意義上來講是不合格的，因爲對於一個系統來說有很多個功能，比如系統登錄、註冊、查詢、刪除等等，是要求登錄達到200，還是所有功能總共達到200，因爲當用戶進入系統之後，有些用戶在執行註冊，有些用戶在執行查詢，是否可以並行操作，也是所謂的併發，所以說要理解集合點和併發數，從根本上就應該更清晰的理解業務流程，只有把業務分析清楚了，方纔可以合理的使用集合點，正確的理解併發用戶數。
當然，就我個人來講，我是很少使用集合點的，因爲通過LoadRunner的理解，我認爲LoadRunner本身就已經在模擬實現一個併發的過程，而增加集合點設置只是爲了並實現嚴格意義上的所謂的併發，而實際是這個集合點的設置也並非絕對達到了這個目的，結構中的過程就可以證明。當然爲此我也通過一些實例來做驗證，以下是對Mercury web Tours網站首頁，錄製訪問過程，腳本如下：
腳本 1：設置集合點
Action()
{
lr_rendezvous("同步訪問web頁面");
lr_start_transaction("start");
web_url("mercuryWebTours",
"URL=http://192.168.3.34:1080/mercuryWebTours/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);
lr_end_transaction("start", LR_AUTO);
return 0;
}
腳本 2：不設置集合點
Action()
{
web_url("mercuryWebTours",
"URL=http://192.168.3.34:1080/mercuryWebTours/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);
return 0;
}
在相同場景實際中執行兩個腳本之後，發現其響應時間其實誤差很小。當然，這只是我實踐中的一個，近期做的其他項目中，包括C/S和B/S都有的，我也都有實踐過，期待有興趣的朋友也可以實踐驗證哈，分享結論。
以上我只是想表達的一個觀點就是，並不是集合點在我們的性能測試中沒有作用，如果沒有作用我相信設計LoadRunner的公司也不會給出來，而是要理解如何選擇去用它，這纔是關鍵。之前我們就講到過，在一些業務流程比較複雜的應用程序測試中，我們就必須要使用集合點，比如一個企業系統中業務是這樣的：用戶登錄進入之後，一部分人在完善個人資料，一部分人在查詢數據，另一部分人在執行刪除操作，還有一部分來發送消息等等。就這樣的一個業務中，在模擬執行性能測試時，就必須明確併發用戶跟集合點的關係，在實際錄製腳本的時候，我們就需要把這個業務分割成多個事務，然後分別對各個不同的事務要設置集合點，爲什麼此時要使用集合點呢，因爲我們必須分析出每一個事務的併發情況，加入200個用戶進去之後，我們就這樣放任去這200個用戶自由去操作，就不能判斷出查詢併發數多少、刪除併發數多少、發送消息的併發又是多少，因爲進入系統之後，沒辦法確定200個用戶都同時幹了些什麼，所以此處纔是集合點使用最合理的地方。至於，我爲什麼很少使用集合點，也源於此，因爲通常情況我們主要是對單一業務進行壓力測試，比如登錄或者是註冊，單一功能就如同上面的那個訪問web頁面一樣，腳本只有一個操作，此時對於LoadRunner來講，其實有沒有設置集合點效果不大，而且爲了模擬能更加接近去實際情況，當然這也是要做實際分析的。
這裏我還要個舉例子，比如，一個OA系統，要求併發用戶數200，而我們的場景設置是這樣的，200個併發用戶平均每10s加載5個用戶，大約運行半小時，此時執行的場景，我們可以結合實際情況進行分析：根據實際情況得出，通常登錄OA系統的的用戶大部分都在早上上班9：00～9：30，此時是一個時間段，而並非一個時間點，使用我們的模擬場景是完全符合實際需求的，所以得出結論是在30分鐘的時間內，我們的OA系統可以允許200個用戶同時進行登錄操作。由此可以說明，任何需求的提出都必須從實際環境來考慮，我們在設置場景時也必須反映出實際情況，才能模擬出更接近真實的場景，得出來的結果才更有價值。
當然，性能測試的執行應該是有目的，通常是爲了調優，也有的是爲了評測
在以評測爲目的的性能測試中，用戶更關心的是業務上的併發，其實是真實業務場景的併發情況，這種情況下就不需要設置集合點了。
集合點是一種特殊情況下的併發，通常是在以調優爲目的的性能測試中才會用得到，主要是爲了有針對性地進行施壓，以便找到性能瓶頸。
以上純屬個人理解，期待拍磚！