網友問題：
例如在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，再運行看看情況。