探討LoadRunner的并發(fā)用戶和集合點(diǎn)

近來(lái)跟蹤一個(gè)項(xiàng)目，發(fā)現(xiàn)同事們?cè)趫?zhí)行性能測(cè)試時(shí)，比較熱衷于使用集合點(diǎn)，從概念上認(rèn)為要得到并發(fā)用戶就必須設(shè)置集合點(diǎn)，認(rèn)為在執(zhí)行一個(gè)壓力測(cè)試腳本時(shí)，設(shè)置了集合點(diǎn)才算是有效的并發(fā)用戶，沒(méi)有設(shè)置結(jié)合點(diǎn)，就認(rèn)為可能這個(gè)就不能準(zhǔn)確的代表并發(fā)用戶數(shù)。當(dāng)前我并反對(duì)這個(gè)觀點(diǎn)，不過(guò)卻讓我有一種疑慮，促使我想更深入的理解并發(fā)用戶和集合點(diǎn)，我相信大多數(shù)進(jìn)入性能測(cè)試研究領(lǐng)域的朋友都應(yīng)該有疑惑，主要原因我覺(jué)得還是由于不能深入理解LoadRunner的實(shí)現(xiàn)原理，而且缺乏對(duì)系統(tǒng)整個(gè)過(guò)程的分析，其中這里面涉及到的知識(shí)包括網(wǎng)絡(luò)、協(xié)議、中間件、數(shù)據(jù)庫(kù)、應(yīng)用層以及緩沖區(qū)和緩存等等，當(dāng)然還與硬件資源CPU隊(duì)列和內(nèi)存等有著千絲萬(wàn)縷的聯(lián)系。所以說(shuō)要成為一個(gè)優(yōu)秀的性能測(cè)試人員，真還不一個(gè)容易的過(guò)程，是需要長(zhǎng)時(shí)間積累和學(xué)習(xí)的，只有通過(guò)大量的項(xiàng)目實(shí)踐和分析，最后再總結(jié)于思想，才有可能成為這個(gè)領(lǐng)域的專家，當(dāng)然也希望真正想把性能測(cè)試做好的朋友都能為此將不懈努力，樂(lè)于分享和討論。

　　先來(lái)看一個(gè)應(yīng)用系統(tǒng)的結(jié)構(gòu)圖，如下所示：

　　這個(gè)圖源于小布老師的視頻中，比較直觀、簡(jiǎn)潔地反映了一個(gè)應(yīng)用系統(tǒng)的運(yùn)行過(guò)程，其中包括客戶端、網(wǎng)絡(luò)、應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器，其中每一個(gè)環(huán)節(jié)都是在執(zhí)行性能測(cè)試分析中必不可少的元素，結(jié)構(gòu)圖中也合理得分析出了響應(yīng)時(shí)間的處理過(guò)程，當(dāng)請(qǐng)求從客戶端發(fā)出之后到最后返回到客戶端，這個(gè)過(guò)程中每一個(gè)環(huán)節(jié)的處理都有可能最后成為系統(tǒng)運(yùn)行中的性能瓶頸，所以可見(jiàn)對(duì)系統(tǒng)整體結(jié)構(gòu)的理解是何等重要。

　　接下來(lái)我們來(lái)看看關(guān)于并發(fā)用戶和集合點(diǎn)的定義：

　　并發(fā)用戶：通俗意義上講就是同時(shí)操作的用戶，當(dāng)然這個(gè)“同時(shí)”可以理解為同一時(shí)間段，還可以理解為同一時(shí)間點(diǎn)，當(dāng)然如果說(shuō)并發(fā)就是同一時(shí)間點(diǎn)上同時(shí)操作的用戶，這樣理解沒(méi)有錯(cuò)誤，但對(duì)于實(shí)際情況來(lái)講，是沒(méi)有嚴(yán)格意義上的并發(fā)執(zhí)行的，就如同進(jìn)程和線程關(guān)系一樣，在某一個(gè)點(diǎn)嚴(yán)格上講就只有一個(gè)人得到執(zhí)行的權(quán)利。

　　集合點(diǎn)：用以同步虛擬用戶，以便恰好在同一時(shí)刻執(zhí)行任務(wù)。這個(gè)從概念上來(lái)講，其實(shí)也是比較模糊，正因?yàn)槟：?，使用才值得去深入探討。?duì)于LoadRunner來(lái)說(shuō)，集合點(diǎn)只是一種策略，而這個(gè)策略也會(huì)有很多規(guī)則，因?yàn)閷?shí)際情況中并非所有用戶都會(huì)同時(shí)到達(dá)集合點(diǎn)，上面的那個(gè)結(jié)構(gòu)圖就能解釋這個(gè)誤解，因?yàn)閺目蛻舳税l(fā)出到網(wǎng)絡(luò)、中間件、應(yīng)用層再到數(shù)據(jù)庫(kù)，這其中的每一個(gè)環(huán)節(jié)都有延時(shí)，也就是說(shuō)不可能所有的用戶都能到達(dá)所謂的集合點(diǎn)，才開(kāi)始同時(shí)執(zhí)行操作。

　　從上面的兩個(gè)概念的理解來(lái)講，有人就會(huì)思考，并發(fā)用戶和集合點(diǎn)到底有沒(méi)有關(guān)系，這才是關(guān)鍵。當(dāng)然這個(gè)就要看需求是什么了，所以說(shuō)很多時(shí)候我們誤用集合點(diǎn)和并發(fā)用戶，其實(shí)根本原因在于對(duì)需求的理解，需求本身都沒(méi)有搞清楚他想實(shí)現(xiàn)的場(chǎng)景，得到什么樣的結(jié)果。當(dāng)然，我們只能感慨需求并是專業(yè)的技術(shù)人員，至少我們大多數(shù)人碰到的需求都不一定是技術(shù)出身，所以他們不明白，我們就不能裝忽悠，不然結(jié)果就肯定不符合實(shí)際了。

　　通常情況下，我們會(huì)得到用戶這樣的需求“本系統(tǒng)要達(dá)到并發(fā)用戶200”，這種需求從嚴(yán)格意義上來(lái)講是不合格的，因?yàn)閷?duì)于一個(gè)系統(tǒng)來(lái)說(shuō)有很多個(gè)功能，比如系統(tǒng)登錄、注冊(cè)、查詢、刪除等等，是要求登錄達(dá)到200，還是所有功能總共達(dá)到200，因?yàn)楫?dāng)用戶進(jìn)入系統(tǒng)之后，有些用戶在執(zhí)行注冊(cè)，有些用戶在執(zhí)行查詢，是否可以并行操作，也是所謂的并發(fā)，所以說(shuō)要理解集合點(diǎn)和并發(fā)數(shù)，從根本上就應(yīng)該更清晰的理解業(yè)務(wù)流程，只有把業(yè)務(wù)分析清楚了，方才可以合理的使用集合點(diǎn)，正確的理解并發(fā)用戶數(shù)。

　　當(dāng)然，就我個(gè)人來(lái)講，我是很少使用集合點(diǎn)的，因?yàn)橥ㄟ^(guò)LoadRunner的理解，我認(rèn)為L(zhǎng)oadRunner本身就已經(jīng)在模擬實(shí)現(xiàn)一個(gè)并發(fā)的過(guò)程，而增加集合點(diǎn)設(shè)置只是為了并實(shí)現(xiàn)嚴(yán)格意義上的所謂的并發(fā)，而實(shí)際是這個(gè)集合點(diǎn)的設(shè)置也并非絕對(duì)達(dá)到了這個(gè)目的，結(jié)構(gòu)中的過(guò)程就可以證明。當(dāng)然為此我也通過(guò)一些實(shí)例來(lái)做驗(yàn)證，以下是對(duì)Mercury web Tours網(wǎng)站首頁(yè)，錄制訪問(wèn)過(guò)程，腳本如下：

　　腳本 1：設(shè)置集合點(diǎn)

Action()
{
lr_rendezvous("同步訪問(wèn)web頁(yè)面");

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：不設(shè)置檢查點(diǎn)

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

　　在相同場(chǎng)景實(shí)際中執(zhí)行兩個(gè)腳本之后，發(fā)現(xiàn)其響應(yīng)時(shí)間其實(shí)誤差很小。當(dāng)然，這只是我實(shí)踐中的一個(gè)，近期做的其他項(xiàng)目中，包括C/S和B/S都有的，我也都有實(shí)踐過(guò)，期待有興趣的朋友也可以實(shí)踐驗(yàn)證哈，分享結(jié)論。

　　以上我只是想表達(dá)的一個(gè)觀點(diǎn)就是，并不是集合點(diǎn)在我們的性能測(cè)試中沒(méi)有作用，如果沒(méi)有作用我相信設(shè)計(jì)LoadRunner的公司也不會(huì)給出來(lái)，而是要理解如何選擇去用它，這才是關(guān)鍵。之前我們就講到過(guò)，在一些業(yè)務(wù)流程比較復(fù)雜的應(yīng)用程序測(cè)試中，我們就必須要使用集合點(diǎn)，比如一個(gè)企業(yè)系統(tǒng)中業(yè)務(wù)是這樣的：用戶登錄進(jìn)入之后，一部分人在完善個(gè)人資料，一部分人在查詢數(shù)據(jù)，另一部分人在執(zhí)行刪除操作，還有一部分來(lái)發(fā)送消息等等。就這樣的一個(gè)業(yè)務(wù)中，在模擬執(zhí)行性能測(cè)試時(shí)，就必須明確并發(fā)用戶跟集合點(diǎn)的關(guān)系，在實(shí)際錄制腳本的時(shí)候，我們就需要把這個(gè)業(yè)務(wù)分割成多個(gè)事務(wù)，然后分別對(duì)各個(gè)不同的事務(wù)要設(shè)置集合點(diǎn)，為什么此時(shí)要使用集合點(diǎn)呢，因?yàn)槲覀儽仨毞治龀雒恳粋€(gè)事務(wù)的并發(fā)情況，加入200個(gè)用戶進(jìn)去之后，我們就這樣放任去這200個(gè)用戶自由去操作，就不能判斷出查詢并發(fā)數(shù)多少、刪除并發(fā)數(shù)多少、發(fā)送消息的并發(fā)又是多少，因?yàn)檫M(jìn)入系統(tǒng)之后，沒(méi)辦法確定200個(gè)用戶都同時(shí)干了些什么，所以此處才是集合點(diǎn)使用最合理的地方。至于，我為什么很少使用集合點(diǎn)，也源于此，因?yàn)橥ǔＧ闆r我們主要是對(duì)單一業(yè)務(wù)進(jìn)行壓力測(cè)試，比如登錄或者是注冊(cè)，單一功能就如同上面的那個(gè)訪問(wèn)web頁(yè)面一樣，腳本只有一個(gè)操作，此時(shí)對(duì)于LoadRunner來(lái)講，其實(shí)有沒(méi)有設(shè)置集合點(diǎn)效果不大，而且為了模擬能更加接近去實(shí)際情況，當(dāng)然這也是要做實(shí)際分析的。

　　這里我還要個(gè)舉例子，比如，一個(gè)OA系統(tǒng)，要求并發(fā)用戶數(shù)200，而我們的場(chǎng)景設(shè)置是這樣的，200個(gè)并發(fā)用戶平均每10s加載5個(gè)用戶，大約運(yùn)行半小時(shí)，此時(shí)執(zhí)行的場(chǎng)景，我們可以結(jié)合實(shí)際情況進(jìn)行分析：根據(jù)實(shí)際情況得出，通常登錄OA系統(tǒng)的的用戶大部分都在早上上班9：00～9：30，此時(shí)是一個(gè)時(shí)間段，而并非一個(gè)時(shí)間點(diǎn)，使用我們的模擬場(chǎng)景是完全符合實(shí)際需求的，所以得出結(jié)論是在30分鐘的時(shí)間內(nèi)，我們的OA系統(tǒng)可以允許200個(gè)用戶同時(shí)進(jìn)行登錄操作。由此可以說(shuō)明，任何需求的提出都必須從實(shí)際環(huán)境來(lái)考慮，我們?cè)谠O(shè)置場(chǎng)景時(shí)也必須反映出實(shí)際情況，才能模擬出更接近真實(shí)的場(chǎng)景，得出來(lái)的結(jié)果才更有價(jià)值。

　　當(dāng)然，性能測(cè)試的執(zhí)行應(yīng)該是有目的，通常是為了調(diào)優(yōu)，也有的是為了評(píng)測(cè)

　　在以評(píng)測(cè)為目的的性能測(cè)試中，用戶更關(guān)心的是業(yè)務(wù)上的并發(fā)，其實(shí)是真實(shí)業(yè)務(wù)場(chǎng)景的并發(fā)情況，這種情況下就不需要設(shè)置集合點(diǎn)了。

　　集合點(diǎn)是一種特殊情況下的并發(fā)，通常是在以調(diào)優(yōu)為目的的性能測(cè)試中才會(huì)用得到，主要是為了有針對(duì)性地進(jìn)行施壓，以便找到性能瓶頸。

　　以上純屬個(gè)人理解