Loadrunner的并發用戶數和集合點分析

林克強，趙秀娟

(1.中國電子科技集團公司第五十四研究所，河北石家莊050081;2.石藥集團河北中誠醫藥有限公司，河北石家莊050081)

0 引言

系統的性能是一個很大的概念，覆蓋面非常廣泛，對一個軟件系統而言，包括執行效率、資源占用、穩定性、安全性、兼容性、可擴展性以及可靠性等。負載壓力是系統性能的一個重要方面，是指在一定約束條件下測試系統所能承受的并發用戶量、運行時間、數據量，以確定系統所能承受的最大負載壓力［3］。在一個大型應用系統里，某些業務操作對特定角色用戶來講存在很大的同時操作的可能性。客戶端大量的并發操作提高了網絡的吞吐量，加劇了服務器資源互斥訪問沖突，加大了數據庫死鎖的可能。這樣的負載壓力輕則會導致系統性能低下，重則會對系統造成破壞，給用戶帶來經濟損失。因此負載壓力測試對于保證系統的性能是非常關鍵的。基于Loadrunner的并發性能測試需要確定并發用戶數和設置集合點，以達到在服務器上創建密集的用戶負載。

1 并發用戶和集合點

關于并發用戶和集合點的定義如下:

并發用戶:通過模擬用戶的并發訪問，測試多用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題［2］。當然這個“同時”可以理解為同一時間段，還可以理解為同一時間點，當然如果說并發就是同一時間點上同時操作的用戶，這樣理解沒有錯誤，但對于實際情況來講，是沒有嚴格意義上的并發執行的，就如同進程和線程關系一樣，在某一個點嚴格上講就只有一個人得到執行的權利。

集合點:用以同步虛擬用戶以便恰好在同一時刻執行任務。可以在服務器上創建密集的用戶負載［1］。對于Loadrunner來說，集合點只是一種策略，而這個策略也會有很多規則，因為實際情況中并非所有用戶都會同時到達集合點，因為從客戶端發出到網絡、中間件、應用層再到數據庫，這其中的每一個環節都有延時，也就是說不可能所有的用戶都能到達所謂的集合點才開始同時執行操作。

從上面2個概念的理解來講，有人就會思考，并發用戶和集合點到底有沒有關系，這才是關鍵。當然這個就要看需求是什么了，所以在很多時候誤用集合點和并發用戶，其實根本原因在于對需求的理解。

2 應用系統組成

從概念上認為要得到并發用戶就必須設置集合點，認為在執行一個壓力測試腳本時，設置了集合點才算是有效的并發用戶，沒有設置集合點，就認為可能這個就不能準確地代表并發用戶數。

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

圖1 應用系統結構圖

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

2.1 測試構建

假設有一個OA系統，該系統有2 000個使用用戶——這就是說，可能使用該OA系統的用戶總數是2 000名，這個概念就是“系統用戶數”，該系統有一個“在線統計”功能(系統用一個全局變量計數所有已登錄的用戶)，從在線統計功能中可以得到，最高峰時有500人在線(這個500就是一般所說的“同時在線人數”)，那么，系統的并發用戶數是多少呢?

根據對并發用戶數的定義，這500就是整個系統使用時最大的業務并發用戶數。當然，500這個數值只是表明在最高峰時刻有500個用戶登錄了系統，并不表示實際服務器承受的壓力。因為服務器承受的壓力還與具體的用戶訪問模式相關。例如，在這500個“同時使用系統”的用戶中，考察某一個時間點，在這個時間上，假設其中40%的用戶在饒有興致地看系統公告(注意:“看”這個動作是不會對服務端產生任何負擔的)，20%的用戶在填寫復雜的表格(對用戶填寫的表格來說，只有在“提交”的時刻才會向服務端發送請求，填寫過程是不對服務端構成壓力的)，20%部分用戶在發呆(也就是什么也沒有做)，剩下的20%用戶在不停地從一個頁面跳轉到另一個頁面——在這種場景下，可以說，只有20%的用戶真正對服務器構成了壓力。因此，從上面的例子中可以看出，服務器實際承受的壓力不只取決于業務并發用戶數，還取決于用戶的業務場景。

所以說要理解集合點和并發數，從根本上就應該更清晰地理解業務流程，只有把業務分析清楚了，方才可以合理地使用集合點，正確地理解并發用戶數。

2.2 測試實踐分析

通過Loadrunner的理解，我認為Loadrunner本身就已經在模擬實現一個并發的過程，而增加集合點設置只是為了實現嚴格意義上的所謂并發，而實際是這個集合點的設置也并非絕對達到了這個目的，結構圖中的過程就可以證明。當然，為此也通過一些實例來做驗證，以下是對cetcbbs內部論壇首頁，錄制訪問過程，腳本如下:

腳本1:設置集合點

在場景中設置100個并發用戶，執行2個腳本之后，可以得到它們的平均事務響應時間，如圖2和圖3所示，從圖中可以看到2個腳本的運行結果相差很小。

圖2 腳本1平均事務響應時間

圖3 腳本2平均事務響應時間

集合點在性能測試中并不是沒有作用，而是要理解如何選擇去用它，這才是關鍵。

在一些業務流程比較復雜的應用程序測試中，就必須要使用集合點。比如一個應用系統中業務是這樣的:用戶登錄進入之后，一部分人在完善資料，一部分人在查詢數據，另一部分人在執行刪除操作，還有一部分人在發送消息等等。就這樣的一個業務中，在模擬執行性能測試時，就必須明確并發用戶跟集合點的關系，在實際錄制腳本的時候，就需要把這個業務分割成多個事務，然后分別對各個不同的事務設置集合點。

為什么此時要使用集合點呢?因為必須分析出每一個事務的并發情況，加入200個用戶進去之后，就這樣放任這200個用戶自由去操作，就不能判斷出查詢并發數多少、刪除并發數多少、發送消息的并發數又是多少，因為進入系統之后，沒辦法確定200個用戶都同時干了些什么，所以此處才是集合點使用最合理的地方。

通常情況，主要是對單一業務進行壓力測試，如登錄或者注冊，單一功能就如同上面的那個訪問web頁面一樣，腳本只有一個操作，此時對于Loadrunner來講，其實有沒有設置集合點效果不大，而且為了模擬能更加接近實際情況，當然這也是要做實際分析的。

3 結束語

性能測試的執行應該是有目的，通常是為了調優，也有的是為了評測。在以評測為目的的性能測試中，用戶更關心的是業務上的并發，其實是真實業務場景的并發情況，這種情況下就不需要設置集合點了。

集合點是一種特殊情況下的并發，通常是在以調優為目的的性能測試中才會用到，主要是為了有針對性的進行施壓，以便找到性能瓶頸。

［1］于涌.軟件性能測試與LOADRUNNER實戰［M］.北京:人民郵電出版社，2008.

［2］段念.軟件性能測試過程詳解與案例剖析［M］.北京:清華大學出版社，2006.

［3］柳純錄.軟件評測師教程［M］.北京:清華大學出版社，2005.