loadrunner中並發數與迭代的區別

網友問題： 

例如在LR里，我要測100個用戶同時並發登陸所用時間，那我是不是在錄制好腳本后，需要參數化“用戶名”，“密碼”以及在那個記事本里構造100個真實的用戶名和密碼？ 然后運行Controller，設置用戶數為100？那么這里的迭代次數該怎么設啊，設成1和設成10有什么區別啊？我老是搞不清測試並發用戶，“迭代”和“並發用戶數”（就是controller里設的虛擬用戶數）的區別。 

 

 

 

ZEE的回答： 

用比喻的方式來回一下： 

 

四車道的馬路，如果只有四輛車並排走過就是並發； 

如果四輛車排成一縱隊走過就是迭代； 

如果有100輛車排成25行依次走過就是並發加迭代。 

在以上說法中，只有並排的車是我們設置的用戶數。 

 

 

以下內容是轉載的，只做記錄一下： 

 

通過用lr做負載壓力測試過程發現，如果設定不同的action迭代次數，每次得出的結果是不同的，曲線的表現形式也是不同的。這點就使我們會感覺困惑,為什么要設置action的迭代次數？以及對於不同的應用系統應該怎樣設置迭代次數呢？ 

 

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

 

性能測試是模擬系統一段時間內真實的壓力情況，以考察系統的性能。 

 

再看怎么模擬系統真實的壓力情況？比如在半個小時內，用戶都在進行登錄操作，且平均分布在這半個小時內。我們要做的是什么？模擬這半個小時用戶的行為。怎么模擬？估算出同時操作的人數，並用LoadRunner不斷的發送登錄請求，這就是我們為什么要迭代。 

 

至於迭代次數，只要能夠模擬出真實情況，多少次都無所謂，不過10次8次估計是模擬不出來。迭代次數至少要保證壓力達到一個穩定值后再運行一段時間，這樣我們得到的數據才是有效的。所以我們除非是特別要求，一般不用迭代次數，而是用運行時間。 

 

1，迭代和並發，是完全不同的概念。沒有什么關系。 

 

比如，一個用戶迭代十次，還是一個用戶的壓力。 

 

10個用戶執行一次，就是10個用戶的壓力。10個用戶迭代10次，還是10個用戶的壓力。但他們都和參數化的數據有關系（也要看參數化是如何設置的，以及系統如何判斷提交值的）。 

 

2,你要是想知道，LR是如何實現迭代和並發： 

 

說一個比較容易理解的層面：迭代就是不停的反復調用同一腳本，反復執行，注意，對1個用戶執行10次來說，只會分配一塊內存。10個用戶執行一次，是調用同一腳本10次，會分配10塊內存。LR調用腳本，編譯后，運行，按腳本發送數據。 

 

比如：web_url這樣的函數，執行就會發HTTP request。 

 

如果你還想知道更細節的進程和函數的實現，只能側面驗證（具體方法看各人的能力和擅長），因為我們都不是LR的開發者。 

 

3,太顯然的問題了，參數化時選擇每次出現唯一，只要參數夠用就OK，不夠用，就設置相應的規則。 

 

action在場景運行中iteration只對其起作用，對vuser_init和vuser_end都不起作用，action是一個可以被重復使用的最小單位其實你可以將所有腳本錄制到一個action里，只是不方便管理罷了。 

 

舉個最簡單的例子，像lr自帶的例子——訂票系統，你如果把所有腳本都錄制到一個action里，那回放的時候，每個用戶登錄就只能買一張票，而如果想一個用戶買多張票的話，這樣就行不通了。那你就要設多個action，並把登錄和結束各錄制在一個action里，把買票錄到一個action中，這樣，將買票的action迭代多次，而用戶登錄和結束只運行一次，這不就模擬了現實中的情況了嗎？ 

 

其實LoadRunner 是以客戶端的角度來定義“響應時間”的，當客戶端請求發出去后， LoadRunner 就開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：如果此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那么該請求會駐留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結束后，我們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果，設置步長則可以緩解這一情況，這樣，應該試試設置pacing，再運行看看情況。

 

 

 

LoadRunner-迭代和並發設置

迭代：指運行一次腳本時某段代碼塊(action)循環執行的次數，串行執行

並發：指同時運行腳本的次數，並行執行（多個用戶同時跑）

 

以下是用例和對應的相關設置

Iterations是在Vuser Generator的Run-time Setting中進行設置

Quantity是在Controller Scenario中進行設置

其余是在Parameter List 中進行設置 

1.select next row：參數值取值的順序

Sequential（順序），Random(隨機)，Unique（唯一 ）三個選項；如果要求使用不同的賬號登錄則設置為Unique；

如果構造的賬號數不夠又對用戶是否相同不做要求，則可以設置Sequential，參數調到最后一列后再從第一列開始調用。

2.update value on ： (什么事件)觸發參數取值更換

each iteration：進入一個迭代更換一次參數值；（sequential時）每個迭代不同用戶使用相同參數值（不管並發是多少）；(unique時)每個迭代不同用戶使用不同值

each occurence :腳本中每次變量出現就換一個新值，謹慎用，用於賬號肯定不行。（比如user1登錄user2權限操作）

once:只取一個值(不管並發和迭代是多少)

 

controller中多用戶並發時候，每個用戶使用完參數化中的數據不在重復使用且每個用戶不使用相同參數化數據的方法

工作中經常遇到標題中這樣的情況，看到群里也經常有人問，操作很簡單，如下：

select next row：Unique(唯一)

說明：每個Vuser取的參數都不一致，確保數據唯一性。

Upate value on:Eachinteration(每次迭代)

說明：每次遇到參數都取一個新值，如果在腳本的一次迭代中，該參數出現兩次，那么兩次都取不同的值。

如圖設置，每次每個用戶取不同的值，保證每個用戶使用的流水號數據唯一

 

 

 

 

 

 

 

 

 

loadrunner中並發數與迭代的區別

錄制腳本時只會有1個虛擬用戶，1個虛擬用戶可以有多次 迭代，也就是 重復執行 Action里面的內容，在場景設置的時候，如果你說的10時在runtime-setting的Run Logic里面設置的，那就是1個虛擬用戶 迭代 10次，並且要求你設置的場景Duration的類型為Run until Completion 時，這個設置才會起作用，如果Duration的類型是Run for <時間>， 這個意思就是1個用戶在這段時間內不停執行Action里面的操作。

 

追問：

不是那個意思，我知道迭代，好像在參數化的時候，在table里面要設置幾個虛擬用戶的用戶名和密碼，在場景設計的時候有10個，不知道這兩個之間的區別，那在錄制腳本的時候比如要多用戶的登錄，在哪里設置用戶數？

 

回答

  

用戶登錄的流程是不是把 用戶名和密碼提交到服務器，每個用戶的用戶名不一樣吧？所以你錄制1個用戶的登錄，然后把這個用戶的操作復制多個，然后把復制的用戶名和密碼都改成唯一的，是不是就有多個用戶了。loadrunner里面的1個虛擬用戶就是1個線程（或者進程），然后把每個線程里面的用戶名改成不同的，啟多個線程，就是多個用戶了。你在寫腳本的時候就是創建1個源文件（被復制的對象），controller的作用就是復制多個線程，復制的線程的用戶名就是從你table里面取出來的。錄制腳本就是創建第一個源文件的過程，controller是多個用戶並發的時候。你可以先看一下loadrunner的用戶手冊

 

腳本迭代的意義是假設設置迭代為N次，運行一次腳本，循環會先在init運行一次，然后在action運行N次，最后在end運行一次，然后退出（假設只有一個action情況下）。
那么首先要說，在場景下面無論是一個用戶還是多個用戶，都是去讀腳本， 如果沒有設集合點，這些用戶完全是各自跑各自的，隨機地跑完同一腳本。第一個問題如果設置時間很短，虛擬用戶也會跑完腳本再停止，也不會報錯。
在腳本里面設置參數的時候可以設置變量在迭代方式上怎么取值，也可以設置不同用戶都是怎么去取值（用戶和用戶之間沒什么關系）假設是M個用戶，腳本迭代N次，那么在跑場景的時候（假設場景設置用戶跑完場景就停止），每一個用戶都會去跑一遍腳本（一個腳本迭代N次action）；如果場景設置5分鍾，則M個用戶自己跑自己的，跑夠五分鍾，然后最后一次腳本跑完，就停止了。

 

並發用戶數量，有兩種常見的錯誤觀點。一種錯誤觀點是把並發用戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把用戶在線數量理解為並發用戶數量。實際上，在線用戶不一定會和其他用戶發生並發，例如正在瀏覽網頁的用戶，對服務器是沒有任何影響的。但是，用戶在線數量是統計並發用戶數量的主要依據之一。並發主要是針對服務器而言，是否並發的關鍵是看用戶操作是否對服務器產生了影響。 因此， 並發用戶數量的正確理解為：在同一時刻與服務器進行了交互的在線用戶數量。這些用戶的最大特征是和服務器產生了交互，這種交互既可以是單向的傳輸數據，也可以是雙向的傳送數據。 比如說：有一個這樣的場景，系統在線用戶是100個，但是同時操作某一個事物（比如說登陸操作）的人是20個那么場景怎么設計了？在Controller中設置100個虛擬用戶執行這個腳本，然后登陸操作之前放一個集合點，然后設置集合點的策略（20個用戶到達時即執行集合點） 對於多個業務場景, 只要錄制多個腳本放在同一個場景內, 然后分配不同比例的虛擬用戶就可以了, 如果不想跑哪個業務場景, 那就不選中這個腳本即可.

 

 

 

追問

   並發用戶數，我可不可以在采集的時候理解為最大的允許vuser值

  回答

   某個腳本設置的vuser值, 可以理解為這個業務場景的並發用戶數,但如果要測試具體某個業務的並發操作,  那就需要設置集合點, 而且集合點數目不能大於vuser值.

 

 

 

 

問題1：LoadRunner是怎么重復迭代和怎么增加並發運行的呢？

 

問題2：另外，在參數化時，對於一次壓力測試中均只能用一次的資源應該怎么參數化呢？就是說這些資源用了一次就不能在用了的。

 

　－－參數化時,在 select   next row選擇unique,update value  on 選擇 each occurence,

 

　1. 迭代跟虛擬用戶數沒什么必然聯系

 

　迭代是這樣的：

 

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

 

　用戶1     X1           X2             X3

 

　用戶2     Y1           X2             Y3

 

　其中的X1-3 Y1-3是參數，參數規則就是二樓說的

 

　這么兩個用戶是根據你的rump up 上來的，比如5秒上兩個用戶，那么用戶1和2就在5秒之內加載進來的，不知道說清楚了沒。

 

　第二個問題就簡單了，只能用一次的參數，首先確保你的參數足夠，另外規則選擇的時候，注意選擇唯一

 

　迭代次數只是對你設置了迭代次數的action進行迭代，而用戶數可以理解為對整個錄制過程的迭代（只是各個用戶不同）　而且增加並發量可以通過增加用戶來達到　還可以設置集合點來增加某個操作的並發量

 

　假如一個腳本，設置最大並發量為10，每5秒中增加2個並發用戶，而Action設置的迭代為10次：

 

　當開始至2秒時，加載了2個用戶，這2個用戶分別開始運行，並都運行10次，不管這個2個用戶運行10次是否結束，當下一個2兩秒到來時，即開始至第4秒時又加載了2個用戶，這2個又運行10次；就這樣一直加載到10個並發用戶，然后當每個用戶都運行完10次時就結束。

 

　這樣中間最大並發是10個，但不一定能達到10個，因為在加載最后幾個時，前面的有可能已經運行結束，所以如果要真正達到最大並發10就必須設置集合點來完成

 

　不過也不一定非要設置集合點才能實現同時處在running的狀態有10個用戶。

 

　設置duration也是可以的。不過那就不只每個用戶運行10次了。

 

　如果想實現用戶迭代10次，並且想同時running為10個用戶，就應該設置集合點。

 

　迭代（Iterate）設計，或者我們稱之為增量（Incremental）設計的思想和XP提倡的Evolutionary Design有異曲同工之妙。