近來跟蹤一個項目，發現同事們在執行性能測試時，比較熱衷於使用集合點，從概念上認為要得到並發用戶就必須設置集合點，認為在執行一個壓力測試腳本時，設置了集合點才算是有效的並發用戶，沒有設置結合點，就認為可能這個就不能準確的代表並發用戶數。當前我並反對這個觀點，不過卻讓我有一種疑慮，促使我想更深入的理解並發用戶和集合點，我相信大多數進入性能測試研究領域的朋友都應該有疑惑，主要原因我覺得還是由於不能深入理解LoadRunner的實現原理，而且缺乏對系統整個過程的分析，其中這裏面涉及到的知識包括網絡、協議、中間件、數據庫、應用層以及緩沖區和緩存等等，當然還與硬件資源CPU隊列和內存等有著千絲萬縷的聯系。所以說要成為一個優秀的性能測試人員，真還不一個容易的過程，是需要長時間積累和學習

　　先來看一個應用系統的結構圖，如下所示：

　　這個圖源於小布老師的視頻中，比較直觀、簡潔地反映了一個應用系統的運行過程，其中包括客戶端、網絡、應用服務器和數據庫服務器，其中每一個環節都是在執行性能測試分析中必不可少的元素，結構圖中也合理得分析出了響應時間的處理過程，當請求從客戶端發出之後到最後返回到客戶端，這個過程中每一個環節的處理都有可能最後成為系統運行中的性能瓶頸，所以可見對系統整體結構的理解是何等重要。

　　接下來我們來看看關於並發用戶和集合點的定義：

　　並發用戶：通俗意義上講就是同時操作的用戶，當然這個“同時”可以理解為同一時間段，還可以理解為同一時間點，當然如果說並發就是同一時間點上同時操作的用戶，這樣理解沒有錯誤，但對於實際情況來講，是沒有嚴格意義上的並發執行的，就如同進程和線程關系一樣，在某一個點嚴格上講就只有一個人得到執行的權利。

　　集合點：用以同步虛擬用戶，以便恰好在同一時刻執行任務。這個從概念上來講，其實也是比較模糊，正因為模糊，使用才值得去深入探討。對於LoadRunner來說，集合點只是一種策略，而這個策略也會有很多規則，因為實際情況中並非所有用戶都會同時到達集合點，上面的那個結構圖就能解釋這個誤解，因為從客戶端發出到網絡、中間件、應用層再到數據庫，這其中的每一個環節都有延時，也就是說不可能所有的用戶都能到達所謂的集合點，才開始同時執行操作。

　　從上面的兩個概念的理解來講，有人就會思考，並發用戶和集合點到底有沒有關系，這才是關鍵。當然這個就要看需求是什麽了，所以說很多時候我們誤用集合點和並發用戶，其實根本原因在於對需求的理解，需求本身都沒有搞清楚他想實現的場景，得到什麽樣的結果。當然，我們只能感慨需求並是專業的技術人員，至少我們大多數人碰到的需求都不一定是技術出身，所以他們不明白，我們就不能裝忽悠，不然結果就肯定不符合實際了。

　　通常情況下，我們會得到用戶這樣的需求“本系統要達到並發用戶200”，這種需求從嚴格意義上來講是不合格的，因為對於一個系統來說有很多個功能，比如系統登錄、註冊、查詢、刪除等等，是要求登錄達到200，還是所有功能總共達到200，因為當用戶進入系統之後，有些用戶在執行註冊，有些用戶在執行查詢，是否可以並行操作，也是所謂的並發，所以說要理解集合點和並發數，從根本上就應該更清晰的理解業務流程，只有把業務分析清楚了，方才可以合理的使用集合點，正確的理解並發用戶數。

　　當然，就我個人來講，我是很少使用集合點的，因為通過LoadRunner的理解，我認為LoadRunner本身就已經在模擬實現一個並發的過程，而增加集合點設置只是為了並實現嚴格意義上的所謂的並發，而實際是這個集合點的設置也並非絕對達到了這個目的，結構中的過程就可以證明。

　在loadrunner的虛擬用戶中，術語concurrent（並發）和simultaneous（同時）存在一些區別，concurrent 是指虛擬場景中參於運行的虛擬用戶。而simultaneous與集合點（rendzvous point）關系更密切，是指在同一時刻一起執行某個任務的虛擬用戶。

　　我們來想象一個場景，10名運動員參加長跑比賽，出發點同時起跑，他們是並排奔跑的；跑了N圈之後，因為有體能更強的，有體能稍弱的，他們的隊形並排變成了前後。幾乎一個跑道就可以供應他們的奔跑（運行），那麽其余的9條跑道就是空閑的。

為了充分的利用跑道，可以將跑道的起點設置一個集合點，當所有運動員跑完一圈後在起跑點集合，然後再同時起跑。

運動員可以看作是虛擬用戶，跑道可以看作是系統資源。設置集合點可以模式更加真實的並發請求，從而增加對系統的負載。

下面是設置集合點的步驟：

1.在Virtual User Generator 中給測試腳本添加集合點函數

註：本例所用腳本是loadrunner軟件自帶的basic腳本

確定腳本中加入集合點的位置（在事務開始之前）=》右擊insert =》選擇集合點Rendezvous

2.保存修改後的腳本，跳轉到controller界面中

tools =》 create controller scenario

3.在controller中設置集合點策略

Scenario ==》 Rendezvous

下面來看看這三種策略的含義：

Release when ：當所有虛擬用戶中的x % 到達集合點進釋放，即僅當指定百分比的虛擬用戶到達集合點時，才釋放虛擬用戶。註意：此選項將會幹擾場景的計劃。如果選擇此選項，場景將不按計劃運行。

Release when ：當所有正在運行的虛擬用戶中的x %到達集合點時釋放，即僅當場景中指定百分比的、正在運行的虛擬用戶到達集合點時，才釋放虛擬用戶。還有不在運行的虛擬用戶？ 假如，設置為1分鐘啟動一個用戶，當然會存在因為用戶還沒啟動，所以無法參與集合點。

Release when ： 當x 個虛擬用戶到達集合點時釋放，即僅當指定數量的虛擬用戶到達集合點時，才釋放虛擬用戶。這個很好理解，當我用百分比不太好衡量集合點的虛擬用戶數，當然可以設置具體的用戶數。

Timeout between Vusers （虛擬用戶之間的超時）框中輸入一個超時值：假如設置了集合10用戶並發，結果9個用戶已經集合到位，還剩1個虛擬用戶，左等右等就是等不來。那總不能一直等下去吧。設定了個時間，假如30秒還不來，那就不管它了。超時的時長默認是30秒，我們可以根據具體的被測應用進行調整。

4.設置運行場景

run_time setting、Scenario Schedule、Global Schedule。。。

5.開始運行

6.結果分析

loadrunner - 集合點