通過用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，再運行看看情況。
