探討LoadRunner的併發用戶和集合點

近來跟蹤一個項目，發現同事們在執行性能測試時，比較熱衷於使用集合點，從概念上認爲要獲得併發用戶就必須設置集合點，認爲在執行一個壓力測試腳本時，設置了集合點纔算是有效的併發用戶，沒有設置結合點，就認爲可能這個就不能準確的表明併發用戶數。當前我並反對這個觀點，不過卻讓我有一種疑慮，促使我想更深刻的理解併發用戶和集合點，我相信大多數進入性能測試研究領域的朋友都應該有疑惑，主要緣由我以爲仍是因爲不能深刻理解LoadRunner的實現原理，並且缺少對系統整個過程的分析，其中這裏面涉及到的知識包括網絡、協議、中間件、數據庫、應用層以及緩衝區和緩存等等，固然還與硬件資源CPU隊列和內存等有着千絲萬縷的聯繫。因此說要成爲一個優秀的性能測試人員，真還不一個容易的過程，是須要長時間積累和學習的，只有經過大量的項目實踐和分析，最後再總結于思想，纔有可能成爲這個領域的專家，固然也但願真正想把性能測試作好的朋友都能爲此將不懈努力，樂於分享和討論。

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

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

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

　　併發用戶：通俗意義上講就是同時操做的用戶，固然這個「同時」能夠理解爲同一時間段，還能夠理解爲同一時間點，固然若是說併發就是同一時間點上同時操做的用戶，這樣理解沒有錯誤，但對於實際狀況來說，是沒有嚴格意義上的併發執行的，就如同進程和線程關係同樣，在某一個點嚴格上講就只有一我的獲得執行的權利。

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

　　從上面的兩個概念的理解來說，有人就會思考，併發用戶和集合點到底有沒有關係，這纔是關鍵。固然這個就要看需求是什麼了，因此說不少時候咱們誤用集合點和併發用戶，其實根本緣由在於對需求的理解，需求自己都沒有搞清楚他想實現的場景，獲得什麼樣的結果。固然，咱們只能感慨需求並是專業的技術人員，至少咱們大多數人碰到的需求都不必定是技術出身，因此他們不明白，咱們就不能裝忽悠，否則結果就確定不符合實際了。

　　一般狀況下，咱們會獲得用戶這樣的需求「本系統要達到併發用戶200」，這種需求從嚴格意義上來說是不合格的，由於對於一個系統來講有不少個功能，好比系統登陸、註冊、查詢、刪除等等，是要求登陸達到200，仍是全部功能總共達到200，由於當用戶進入系統以後，有些用戶在執行註冊，有些用戶在執行查詢，是否能夠並行操做，也是所謂的併發，因此說要理解集合點和併發數，從根本上就應該更清晰的理解業務流程，只有把業務分析清楚了，方纔能夠合理的使用集合點，正確的理解併發用戶數。

　　固然，就我我的來說，我是不多使用集合點的，由於經過LoadRunner的理解，我認爲LoadRunner自己就已經在模擬實現一個併發的過程，而增長集合點設置只是爲了並實現嚴格意義上的所謂的併發，而實際是這個集合點的設置也並不是絕對達到了這個目的，結構中的過程就能夠證實。固然爲此我也經過一些實例來作驗證，如下是對Mercury web Tours網站首頁，錄製訪問過程，腳本以下：

　　腳本 1：設置集合點

Action()
{
lr_rendezvous("同步訪問web頁面");

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;
}

　　腳本 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個用戶同時進行登陸操做。由此能夠說明，任何需求的提出都必須從實際環境來考慮，咱們在設置場景時也必須反映出實際狀況，才能模擬出更接近真實的場景，得出來的結果才更有價值。

　　固然，性能測試的執行應該是有目的，一般是爲了調優，也有的是爲了評測

　　在以評測爲目的的性能測試中，用戶更關心的是業務上的併發，實際上是真實業務場景的併發狀況，這種狀況下就不須要設置集合點了。

　　集合點是一種特殊狀況下的併發，一般是在以調優爲目的的性能測試中才會用獲得，主要是爲了有針對性地進行施壓，以便找到性能瓶頸。

　　以上純屬我的理解