近來跟蹤一個(gè)項(xiàng)目，發(fā)現(xiàn)同事們在執(zhí)行性能測試時(shí)，比較熱衷于使用集合點(diǎn)，從概念上認(rèn)為要得到并發(fā)用戶就必須設(shè)置集合點(diǎn)，認(rèn)為在執(zhí)行一個(gè)壓力測試腳本時(shí)，設(shè)置了集合點(diǎn)才算是有效的并發(fā)用戶，沒有設(shè)置結(jié)合點(diǎn)，就認(rèn)為可能這個(gè)就不能準(zhǔn)確的代表并發(fā)用戶數(shù)。當(dāng)前我并反對這個(gè)觀點(diǎn)，不過卻讓我有一種疑慮，促使我想更深入的理解并發(fā)用戶和集合點(diǎn)，我相信大多數(shù)進(jìn)入性能測試研究領(lǐng)域的朋友都應(yīng)該有疑惑，主要原因我覺得還是由于不能深入理解LoadRunner的實(shí)現(xiàn)原理，而且缺乏對系統(tǒng)整個(gè)過程的分析，其中這里面涉及到的知識(shí)包括網(wǎng)絡(luò)、協(xié)議、中間件、數(shù)據(jù)庫、應(yīng)用層以及緩沖區(qū)和緩存等等，當(dāng)然還與硬件資源CPU隊(duì)列和內(nèi)存等有著千絲萬縷的聯(lián)系。所以說要成為一個(gè)優(yōu)秀的性能測試人員，真還不一個(gè)容易的過程，是需要長時(shí)間積累和學(xué)習(xí)的，只有通過大量的項(xiàng)目實(shí)踐和分析，最后再總結(jié)于思想，才有可能成為這個(gè)領(lǐng)域的專家，當(dāng)然也希望真正想把性能測試做好的朋友都能為此將不懈努力，樂于分享和討論。
先來看一個(gè)應(yīng)用系統(tǒng)的結(jié)構(gòu)圖，如下所示：
這個(gè)圖源于小布老師的視頻中，比較直觀、簡潔地反映了一個(gè)應(yīng)用系統(tǒng)的運(yùn)行過程，其中包括客戶端、網(wǎng)絡(luò)、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，其中每一個(gè)環(huán)節(jié)都是在執(zhí)行性能測試分析中必不可少的元素，結(jié)構(gòu)圖中也合理得分析出了響應(yīng)時(shí)間的處理過程，當(dāng)請求從客戶端發(fā)出之后到最后返回到客戶端，這個(gè)過程中每一個(gè)環(huán)節(jié)的處理都有可能最后成為系統(tǒng)運(yùn)行中的性能瓶頸，所以可見對系統(tǒng)整體結(jié)構(gòu)的理解是何等重要。
接下來我們來看看關(guān)于并發(fā)用戶和集合點(diǎn)的定義：
并發(fā)用戶：通俗意義上講就是同時(shí)操作的用戶，當(dāng)然這個(gè)“同時(shí)”可以理解為同一時(shí)間段，還可以理解為同一時(shí)間點(diǎn)，當(dāng)然如果說并發(fā)就是同一時(shí)間點(diǎn)上同時(shí)操作的用戶，這樣理解沒有錯(cuò)誤，但對于實(shí)際情況來講，是沒有嚴(yán)格意義上的并發(fā)執(zhí)行的，就如同進(jìn)程和線程關(guān)系一樣，在某一個(gè)點(diǎn)嚴(yán)格上講就只有一個(gè)人得到執(zhí)行的權(quán)利。
集合點(diǎn)：用以同步虛擬用戶，以便恰好在同一時(shí)刻執(zhí)行任務(wù)。這個(gè)從概念上來講，其實(shí)也是比較模糊，正因?yàn)槟：?，使用才值得去深入探討。對于LoadRunner來說，集合點(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ù)庫，這其中的每一個(gè)環(huán)節(jié)都有延時(shí)，也就是說不可能所有的用戶都能到達(dá)所謂的集合點(diǎn)，才開始同時(shí)執(zhí)行操作。
從上面的兩個(gè)概念的理解來講，有人就會(huì)思考，并發(fā)用戶和集合點(diǎn)到底有沒有關(guān)系，這才是關(guān)鍵。當(dāng)然這個(gè)就要看需求是什么了，所以說很多時(shí)候我們誤用集合點(diǎn)和并發(fā)用戶，其實(shí)根本原因在于對需求的理解，需求本身都沒有搞清楚他想實(shí)現(xiàn)的場景，得到什么樣的結(jié)果。當(dāng)然，我們只能感慨需求并是專業(yè)的技術(shù)人員，至少我們大多數(shù)人碰到的需求都不一定是技術(shù)出身，所以他們不明白，我們就不能裝忽悠，不然結(jié)果就肯定不符合實(shí)際了。
通常情況下，我們會(huì)得到用戶這樣的需求“本系統(tǒng)要達(dá)到并發(fā)用戶200”，這種需求從嚴(yán)格意義上來講是不合格的，因?yàn)閷τ谝粋€(gè)系統(tǒng)來說有很多個(gè)功能，比如系統(tǒng)登錄、注冊、查詢、刪除等等，是要求登錄達(dá)到200，還是所有功能總共達(dá)到200，因?yàn)楫?dāng)用戶進(jìn)入系統(tǒng)之后，有些用戶在執(zhí)行注冊，有些用戶在執(zhí)行查詢，是否可以并行操作，也是所謂的并發(fā)，所以說要理解集合點(diǎn)和并發(fā)數(shù)，從根本上就應(yīng)該更清晰的理解業(yè)務(wù)流程，只有把業(yè)務(wù)分析清楚了，方才可以合理的使用集合點(diǎn)，正確的理解并發(fā)用戶數(shù)。
當(dāng)然，就我個(gè)人來講，我是很少使用集合點(diǎn)的，因?yàn)橥ㄟ^LoadRunner的理解，我認(rèn)為LoadRunner本身就已經(jīng)在模擬實(shí)現(xiàn)一個(gè)并發(fā)的過程，而增加集合點(diǎn)設(shè)置只是為了并實(shí)現(xiàn)嚴(yán)格意義上的所謂的并發(fā)，而實(shí)際是這個(gè)集合點(diǎn)的設(shè)置也并非絕對達(dá)到了這個(gè)目的，結(jié)構(gòu)中的過程就可以證明。當(dāng)然為此我也通過一些實(shí)例來做驗(yàn)證，以下是對Mercury web Tours網(wǎng)站首頁，錄制訪問過程，腳本如下：
腳本 1：設(shè)置集合點(diǎn)
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：不設(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;
}
在相同場景實(shí)際中執(zhí)行兩個(gè)腳本之后，發(fā)現(xiàn)其響應(yīng)時(shí)間其實(shí)誤差很小。當(dāng)然，這只是我實(shí)踐中的一個(gè)，近期做的其他項(xiàng)目中，包括C/S和B/S都有的，我也都有實(shí)踐過，期待有興趣的朋友也可以實(shí)踐驗(yàn)證哈，分享結(jié)論。
以上我只是想表達(dá)的一個(gè)觀點(diǎn)就是，并不是集合點(diǎn)在我們的性能測試中沒有作用，如果沒有作用我相信設(shè)計(jì)LoadRunner的公司也不會(huì)給出來，而是要理解如何選擇去用它，這才是關(guān)鍵。之前我們就講到過，在一些業(yè)務(wù)流程比較復(fù)雜的應(yīng)用程序測試中，我們就必須要使用集合點(diǎn)，比如一個(gè)企業(yè)系統(tǒng)中業(yè)務(wù)是這樣的：用戶登錄進(jìn)入之后，一部分人在完善個(gè)人資料，一部分人在查詢數(shù)據(jù)，另一部分人在執(zhí)行刪除操作，還有一部分來發(fā)送消息等等。就這樣的一個(gè)業(yè)務(wù)中，在模擬執(zhí)行性能測試時(shí)，就必須明確并發(fā)用戶跟集合點(diǎn)的關(guān)系，在實(shí)際錄制腳本的時(shí)候，我們就需要把這個(gè)業(yè)務(wù)分割成多個(gè)事務(wù)，然后分別對各個(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)之后，沒辦法確定200個(gè)用戶都同時(shí)干了些什么，所以此處才是集合點(diǎn)使用最合理的地方。至于，我為什么很少使用集合點(diǎn)，也源于此，因?yàn)橥ǔＧ闆r我們主要是對單一業(yè)務(wù)進(jìn)行壓力測試，比如登錄或者是注冊，單一功能就如同上面的那個(gè)訪問web頁面一樣，腳本只有一個(gè)操作，此時(shí)對于LoadRunner來講，其實(shí)有沒有設(shè)置集合點(diǎn)效果不大，而且為了模擬能更加接近去實(shí)際情況，當(dāng)然這也是要做實(shí)際分析的。
這里我還要個(gè)舉例子，比如，一個(gè)OA系統(tǒng)，要求并發(fā)用戶數(shù)200，而我們的場景設(shè)置是這樣的，200個(gè)并發(fā)用戶平均每10s加載5個(gè)用戶，大約運(yùn)行半小時(shí)，此時(shí)執(zhí)行的場景，我們可以結(jié)合實(shí)際情況進(jìn)行分析：根據(jù)實(shí)際情況得出，通常登錄OA系統(tǒng)的的用戶大部分都在早上上班9：00～9：30，此時(shí)是一個(gè)時(shí)間段，而并非一個(gè)時(shí)間點(diǎn)，使用我們的模擬場景是完全符合實(shí)際需求的，所以得出結(jié)論是在30分鐘的時(shí)間內(nèi)，我們的OA系統(tǒng)可以允許200個(gè)用戶同時(shí)進(jìn)行登錄操作。由此可以說明，任何需求的提出都必須從實(shí)際環(huán)境來考慮，我們在設(shè)置場景時(shí)也必須反映出實(shí)際情況，才能模擬出更接近真實(shí)的場景，得出來的結(jié)果才更有價(jià)值。
當(dāng)然，性能測試的執(zhí)行應(yīng)該是有目的，通常是為了調(diào)優(yōu)，也有的是為了評測
在以評測為目的的性能測試中，用戶更關(guān)心的是業(yè)務(wù)上的并發(fā)，其實(shí)是真實(shí)業(yè)務(wù)場景的并發(fā)情況，這種情況下就不需要設(shè)置集合點(diǎn)了。
集合點(diǎn)是一種特殊情況下的并發(fā)，通常是在以調(diào)優(yōu)為目的的性能測試中才會(huì)用得到，主要是為了有針對性地進(jìn)行施壓，以便找到性能瓶頸。
以上純屬個(gè)人理解
重慶分公司
重慶分公司
