轉(zhuǎn)載：

例如在LR里，我要測(cè)100個(gè)用戶(hù)同時(shí)并發(fā)登陸所用時(shí)間，那我是不是在錄制好腳本后，需要參數(shù)化“用戶(hù)名”，

“密碼”以及在那個(gè)記事本里構(gòu)造100個(gè)真實(shí)的用戶(hù)名和密碼？ 然后運(yùn)行Controller，

設(shè)置用戶(hù)數(shù)為100？那么這里的迭代次數(shù)該怎么設(shè)啊，設(shè)成1和設(shè)成10有什么區(qū)別??？

我老是搞不清測(cè)試并發(fā)用戶(hù)，“迭代”和“并發(fā)用戶(hù)數(shù)”（就是controller里設(shè)的虛擬用戶(hù)數(shù)）的區(qū)別。

ZEE的回答：

用比喻的方式來(lái)回一下：

四車(chē)道的馬路，如果只有四輛車(chē)并排走過(guò)就是并發(fā)；

? ? ? ? ? ? ? 如果四輛車(chē)排成一縱隊(duì)走過(guò)就是迭代；

? ? ? ? ? ? ? 如果有100輛車(chē)排成25行依次走過(guò)就是并發(fā)加迭代。

在以上說(shuō)法中，只有并排的車(chē)是我們?cè)O(shè)置的用戶(hù)數(shù)。

以下內(nèi)容是轉(zhuǎn)載的，只做記錄一下：

通過(guò)用lr做負(fù)載壓力測(cè)試過(guò)程發(fā)現(xiàn)，如果設(shè)定不同的action迭代次數(shù)，每次得出的結(jié)果是不同的，曲線的表現(xiàn)形式也是不同的。

這點(diǎn)就使我們會(huì)感覺(jué)困惑,為什么要設(shè)置action的迭代次數(shù)？以及對(duì)于不同的應(yīng)用系統(tǒng)應(yīng)該怎樣設(shè)置迭代次數(shù)呢？

首先你要理解性能測(cè)試是在干什么？

性能測(cè)試是模擬系統(tǒng)一段時(shí)間內(nèi)真實(shí)的壓力情況，以考察系統(tǒng)的性能。

再看怎么模擬系統(tǒng)真實(shí)的壓力情況？比如在半個(gè)小時(shí)內(nèi)，用戶(hù)都在進(jìn)行登錄操作，且平均分布在這半個(gè)小時(shí)內(nèi)。我們要做的是什么？

模擬這半個(gè)小時(shí)用戶(hù)的行為。怎么模擬？估算出同時(shí)操作的人數(shù)，并用LoadRunner不斷的發(fā)送登錄請(qǐng)求，這就是我們?yōu)槭裁匆?/p>

至于迭代次數(shù)，只要能夠模擬出真實(shí)情況，多少次都無(wú)所謂，不過(guò)10次8次估計(jì)是模擬不出來(lái)。

迭代次數(shù)至少要保證壓力達(dá)到一個(gè)穩(wěn)定值后再運(yùn)行一段時(shí)間，這樣我們得到的數(shù)據(jù)才是有效的。

所以我們除非是特別要求，一般不用迭代次數(shù)，而是用運(yùn)行時(shí)間。

1，迭代和并發(fā)，是完全不同的概念。沒(méi)有什么關(guān)系。

比如，一個(gè)用戶(hù)迭代十次，還是一個(gè)用戶(hù)的壓力。

10個(gè)用戶(hù)執(zhí)行一次，就是10個(gè)用戶(hù)的壓力。10個(gè)用戶(hù)迭代10次，還是10個(gè)用戶(hù)的壓力。但他們都和參數(shù)化的數(shù)據(jù)有關(guān)系

（也要看參數(shù)化是如何設(shè)置的，以及系統(tǒng)如何判斷提交值的）。

2,你要是想知道，LR是如何實(shí)現(xiàn)迭代和并發(fā)：

說(shuō)一個(gè)比較容易理解的層面：迭代就是不停的反復(fù)調(diào)用同一腳本，反復(fù)執(zhí)行，注意，

對(duì)1個(gè)用戶(hù)執(zhí)行10次來(lái)說(shuō)，只會(huì)分配一塊內(nèi)存。

10個(gè)用戶(hù)執(zhí)行一次，是調(diào)用同一腳本10次，會(huì)分配10塊內(nèi)存。

LR調(diào)用腳本，編譯后，運(yùn)行，按腳本發(fā)送數(shù)據(jù)。

比如：web_url這樣的函數(shù)，執(zhí)行就會(huì)發(fā)HTTP request。

如果你還想知道更細(xì)節(jié)的進(jìn)程和函數(shù)的實(shí)現(xiàn)，只能側(cè)面驗(yàn)證（具體方法看各人的能力和擅長(zhǎng)），因?yàn)槲覀兌疾皇荓R的開(kāi)發(fā)者。

3,太顯然的問(wèn)題了，參數(shù)化時(shí)選擇每次出現(xiàn)唯一，只要參數(shù)夠用就OK，不夠用，就設(shè)置相應(yīng)的規(guī)則。

action在場(chǎng)景運(yùn)行中iteration只對(duì)其起作用，對(duì)vuser_init和vuser_end都不起作用，

action是一個(gè)可以被重復(fù)使用的最小單位其實(shí)你可以將所有腳本錄制到一個(gè)action里，只是不方便管理罷了。

舉個(gè)最簡(jiǎn)單的例子，

像lr自帶的例子——訂票系統(tǒng)，你如果把所有腳本都錄制到一個(gè)action里，

那回放的時(shí)候，每個(gè)用戶(hù)登錄就只能買(mǎi)一張票，而如果想一個(gè)用戶(hù)買(mǎi)多張票的話(huà)，這樣就行不通了。

那你就要設(shè)多個(gè)action，并把登錄和結(jié)束各錄制在一個(gè)action里，把買(mǎi)票錄到一個(gè)action中，

這樣，將買(mǎi)票的action迭代多次，而用戶(hù)登錄和結(jié)束只運(yùn)行一次，這不就模擬了現(xiàn)實(shí)中的情況了嗎？

其實(shí)LoadRunner 是以客戶(hù)端的角度來(lái)定義“響應(yīng)時(shí)間”的，

當(dāng)客戶(hù)端請(qǐng)求發(fā)出去后， LoadRunner 就開(kāi)始計(jì)算響應(yīng)時(shí)間，一直到它收到服務(wù)器端的響應(yīng)。

這個(gè)時(shí)候問(wèn)題就產(chǎn)生了：如果此時(shí)的服務(wù)器端的排隊(duì)隊(duì)列已滿(mǎn)，服務(wù)器資源正處于忙碌的狀態(tài)，

那么該請(qǐng)求會(huì)駐留在服務(wù)器的線程中，換句話(huà)說(shuō)，這個(gè)新產(chǎn)生的請(qǐng)求并不會(huì)對(duì)服務(wù)器端產(chǎn)生真正的負(fù)載，

但很遺憾的是，該請(qǐng)求的計(jì)時(shí)器已經(jīng)啟動(dòng)了，因此我們很容易就可以預(yù)見(jiàn)到，

這個(gè)請(qǐng)求的響應(yīng)時(shí)間會(huì)變得很長(zhǎng)，

甚至可能長(zhǎng)到使得該請(qǐng)求由于超時(shí)而失敗。

等到測(cè)試結(jié)束后，

我們查看一下結(jié)果，就會(huì)發(fā)現(xiàn)這樣一個(gè)很不幸的現(xiàn)象：

事務(wù)平均響應(yīng)時(shí)間很長(zhǎng)，最小響應(yīng)時(shí)間與最大響應(yīng)時(shí)間的差距很大，

而這個(gè)時(shí)候的平均響應(yīng)時(shí)間，其實(shí)也就失去了它應(yīng)有的意義。

也就是說(shuō)，由于客戶(hù)端發(fā)送的請(qǐng)求太快而導(dǎo)致影響了實(shí)際的測(cè)量結(jié)果，

設(shè)置步長(zhǎng)則可以緩解這一情況，這樣，應(yīng)該試試設(shè)置pacing，再運(yùn)行看看情況。

并發(fā)用戶(hù)數(shù)量，有兩種常見(jiàn)的錯(cuò)誤觀點(diǎn)。

一種錯(cuò)誤觀點(diǎn)是把并發(fā)用戶(hù)數(shù)量理解為使用系統(tǒng)的全部用戶(hù)的數(shù)量，理由是這些用戶(hù)可能同時(shí)使用系統(tǒng)；

還有一種比較接近正確的觀點(diǎn)是把用戶(hù)在線數(shù)量理解為并發(fā)用戶(hù)數(shù)量。

實(shí)際上，在線用戶(hù)不一定會(huì)和其他用戶(hù)發(fā)生并發(fā)，例如正在瀏覽網(wǎng)頁(yè)的用戶(hù)，對(duì)服務(wù)器是沒(méi)有任何影響的。

但是，用戶(hù)在線數(shù)量是統(tǒng)計(jì)并發(fā)用戶(hù)數(shù)量的主要依據(jù)之一。

并發(fā)主要是針對(duì)服務(wù)器而言，是否并發(fā)的關(guān)鍵是看用戶(hù)操作是否對(duì)服務(wù)器產(chǎn)生了影響。

因此，并發(fā)用戶(hù)數(shù)量的正確理解為：在同一時(shí)刻與服務(wù)器進(jìn)行了交互的在線用戶(hù)數(shù)量。

這些用戶(hù)的最大特征是和服務(wù)器產(chǎn)生了交互，這種交互既可以是單向的傳輸數(shù)據(jù)，也可以是雙向的傳送數(shù)據(jù)。

比如說(shuō)：有一個(gè)這樣的場(chǎng)景，系統(tǒng)在線用戶(hù)是100個(gè)，但是同時(shí)操作某一個(gè)事物（比如說(shuō)登陸操作）的人是20個(gè)那么場(chǎng)景怎么設(shè)計(jì)了？

在Controller中設(shè)置100個(gè)虛擬用戶(hù)執(zhí)行這個(gè)腳本，然后登陸操作之前放一個(gè)集合點(diǎn)，然后設(shè)置集合點(diǎn)的策略（20個(gè)用戶(hù)到達(dá)時(shí)即執(zhí)行集合點(diǎn)）

對(duì)于多個(gè)業(yè)務(wù)場(chǎng)景, 只要錄制多個(gè)腳本放在同一個(gè)場(chǎng)景內(nèi), 然后分配不同比例的虛擬用戶(hù)就可以了,

如果不想跑哪個(gè)業(yè)務(wù)場(chǎng)景, 那就不選中這個(gè)腳本即可.

追問(wèn)

并發(fā)用戶(hù)數(shù)，我可不可以在采集的時(shí)候理解為最大的允許vuser值

回答

某個(gè)腳本設(shè)置的vuser值, 可以理解為這個(gè)業(yè)務(wù)場(chǎng)景的并發(fā)用戶(hù)數(shù),但如果要測(cè)試具體某個(gè)業(yè)務(wù)的并發(fā)操作,? 那就需要設(shè)置集合點(diǎn),

而且集合點(diǎn)數(shù)目不能大于vuser值.

　LoadRunner是怎么重復(fù)迭代和怎么增加并發(fā)運(yùn)行的呢？

　　另外，在參數(shù)化時(shí)，對(duì)于一次壓力測(cè)試中均只能用一次的資源應(yīng)該怎么參數(shù)化呢？就是說(shuō)這些資源用了一次就不能在用了的。

　　－－參數(shù)化時(shí),在select? next row選擇unique,update value on選擇 each occurence,

　　1. 迭代跟虛擬用戶(hù)數(shù)沒(méi)什么必然聯(lián)系

　　迭代是這樣的：

　　迭代1次? 迭代2次? 迭代3次

　　用戶(hù)1? ? X1? ? ? ? ? X2? ? ? ? ? ? X3

　　用戶(hù)2? ? Y1? ? ? ? ? Y2? ? ? ? ? ? Y3

　　其中的X1-3 Y1-3是參數(shù)，參數(shù)規(guī)則就是二樓說(shuō)的

　　這么兩個(gè)用戶(hù)是根據(jù)你的rump up 上來(lái)的，比如5秒上兩個(gè)用戶(hù)，那么用戶(hù)1和2就在5秒之內(nèi)加載進(jìn)來(lái)的，不知道說(shuō)清楚了沒(méi)。

　　第二個(gè)問(wèn)題就簡(jiǎn)單了，只能用一次的參數(shù)，首先確保你的參數(shù)足夠，另外規(guī)則選擇的時(shí)候，注意選擇唯一

　　迭代次數(shù)只是對(duì)你設(shè)置了迭代次數(shù)的action進(jìn)行迭代，而用戶(hù)數(shù)可以理解為對(duì)整個(gè)錄制過(guò)程的迭代（只是各個(gè)用戶(hù)不同）

? ? 而且增加并發(fā)量可以通過(guò)增加用戶(hù)來(lái)達(dá)到　還可以設(shè)置集合點(diǎn)來(lái)增加某個(gè)操作的并發(fā)量

　　假如一個(gè)腳本，設(shè)置最大并發(fā)量為10，每5秒中增加2個(gè)并發(fā)用戶(hù)，而Action設(shè)置的迭代為10次：

　　當(dāng)開(kāi)始至2秒時(shí)，加載了2個(gè)用戶(hù)，這2個(gè)用戶(hù)分別開(kāi)始運(yùn)行，并都運(yùn)行10次，不管這個(gè)2個(gè)用戶(hù)運(yùn)行10次是否結(jié)束，當(dāng)下一個(gè)2兩秒到來(lái)時(shí)，

? ? 即開(kāi)始至第4秒時(shí)又加載了2個(gè)用戶(hù)，這2個(gè)又運(yùn)行10次；就這樣一直加載到10個(gè)并發(fā)用戶(hù)，然后當(dāng)每個(gè)用戶(hù)都運(yùn)行完10次時(shí)就結(jié)束。

　　這樣中間最大并發(fā)是10個(gè)，但不一定能達(dá)到10個(gè)，因?yàn)樵诩虞d最后幾個(gè)時(shí)，前面的有可能已經(jīng)運(yùn)行結(jié)束，

? ? 所以如果要真正達(dá)到最大并發(fā)10就必須設(shè)置集合點(diǎn)來(lái)完成

　　不過(guò)也不一定非要設(shè)置集合點(diǎn)才能實(shí)現(xiàn)同時(shí)處在running的狀態(tài)有10個(gè)用戶(hù)。

　　設(shè)置duration也是可以的。不過(guò)那就不只每個(gè)用戶(hù)運(yùn)行10次了。

　　如果想實(shí)現(xiàn)用戶(hù)迭代10次，并且想同時(shí)running為10個(gè)用戶(hù)，就應(yīng)該設(shè)置集合點(diǎn)。

　　迭代（Iterate）設(shè)計(jì)，或者我們稱(chēng)之為增量（Incremental）設(shè)計(jì)的思想和XP提倡的Evolutionary Design有異曲同工之妙。