王磊
摘 要 在現行階段很多人士比較熱衷于使用集合點,從概念上認為要得到并發用戶就必須設置集合點,認為在執行一個壓力測試腳本時,設置了集合點才算是有效的并發用戶,沒有設置結合點,就認為可能這個就不能準確的代表并發用戶數。對并發用戶和集合點,缺乏對系統整個過程的分析,這其中涉及到的知識包括網絡、協議、中間件、數據庫、應用層以及緩沖區和緩存等等,當然還與硬件資源CPU隊列和內存等有著千絲萬縷的聯系。
關鍵詞 LoadRunner 并發用戶 集合點
中圖分類號:TP391.4 文獻標識碼:A
1關于并發用戶和集合點的定義
并發用戶:通俗意義上講就是同時操作的用戶,當然這個“同時”可以理解為同一時間段,還可以理解為同一時間點。如果說并發就是同一時間點上同時操作的用戶,這樣理解沒有錯誤,但對于實際情況來講,是沒有嚴格意義上的并發執行的,就如同進程和線程關系一樣,在某一個點嚴格上講就只有一個人得到執行的權利。集合點:用以同步虛擬用戶,以便恰好在同一時刻執行任務。這個從概念上來講,其實也是比較模糊,正因為模糊,使用才值得去深入探討。對于LoadRunner來說,集合點只是一種策略,而這個策略也會有很多規則,因為實際情況中并非所有用戶都會同時到達集合點,因為從客戶端發出到網絡、中間件、應用層再到數據庫,這其中的每一個環節都有延時,也就是說不可能所有的用戶都能到達所謂的集合點,才開始同時執行操作。
2關于并發用戶和集合點的個人理解
從上面兩個概念的理解來講,有人就會思考,并發用戶和集合點到底有沒有關系,這才是關鍵。當然這個就要看需求是什么了,所以說很多時候人們誤用集合點和并發用戶,其實根本原因在于對需求的理解,需求本身都沒有搞清楚想實現的場景,得到什么樣的結果。當然需求并不是專業的技術人員,至少大多數人碰到的需求都不一定是技術出身,所以他們不明白,我們就不能裝忽悠,不然結果就肯定不符合實際了。通常情況下,我們會得到用戶這樣的需求“本系統要達到并發用戶200”,這種需求從嚴格意義上來講是不合格的,因為對于一個系統來說有很多個功能,比如系統登錄、注冊、查詢、刪除等等,是要求登錄達到200,還是所有功能總共達到200,因為當用戶進入系統之后,有些用戶在執行注冊,有些用戶在執行查詢,是否可以并行操作,也是所謂的并發,所以說要理解集合點和并發數,從根本上就應該更清晰的理解業務流程,只有把業務分析清楚了,方才可以合理的使用集合點,正確的理解并發用戶數。通過對LoadRunner的理解,LoadRunner本身就已經在模擬實現一個并發的過程,而增加集合點設置只是為了并實現嚴格意義上的所謂的并發,而實際是這個集合點的設置也并非絕對達到了這個目的,結構中的過程就可以證明。
3設置腳本集合點和不設置檢查點的對比
在相同場景實際中執行兩個腳本之后,發現其響應時間誤差很小。在其他項目中包括C/S和B/S都有的,很多項目都實踐過,并不是集合點在我們的性能測試中沒有作用,如果沒有作用相信設計LoadRunner的公司也不會給出來,而是要理解如何選擇去用它,這才是關鍵。之前就講到過,在一些業務流程比較復雜的應用程序測試中,就必須要使用集合點,比如一個企業系統中業務是這樣的:用戶登錄進入之后,一部分人在完善個人資料,一部分人在查詢數據,另一部分人在執行刪除操作,還有一部分來發送消息等等。就這樣的一個業務中,在模擬執行性能測試時,就必須明確并發用戶跟集合點的關系,在實際錄制腳本的時候,就需要把這個業務分割成多個事務,然后分別對各個不同的事務設置集合點,為什么此時要使用集合點呢,因為我們必須分析出每一個事務的并發情況,加入200個用戶進去之后,就這樣放任去這200個用戶自由去操作,就不能判斷出查詢并發數多少、刪除并發數多少、發送消息的并發又是多少,因為進入系統之后,沒辦法確定200個用戶都同時干了些什么,所以此處才是集合點使用最合理的地方。至于使用集合點,也源于此,因為通常情況我們主要是對單一業務進行壓力測試,比如登錄或者是注冊,單一功能就如同上面的那個訪問web頁面一樣,腳本只有一個操作,此時對于LoadRunner來講,其實有沒有設置集合點效果不大,而且為了模擬能更加接近實際情況,也是需要做實際分析的。
4結論
總之,性能測試的執行應該是有目的的,通常是為了調優,也有的是為了評測,在以評測為目的的性能測試中,用戶更關心的是業務上的并發,其實是真實業務場景的并發情況,這種情況下就不需要設置集合點了。集合點是一種特殊情況下的并發,通常是在以調優為目的的性能測試中才會用得到,主要是為了有針對性地進行施壓,以便找到性能瓶頸。