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

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

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

　　再看怎么模擬系統(tǒng)真實的壓力情況？比如在半個小時內，用戶都在進行登錄操作，且平均分布在這半個小時內。我們要做的是什么？模擬這半個小時用戶的行為。怎么模擬？估算出同時操作的人數，并用LoadRunner不斷的發(fā)送登錄請求，這就是我們?yōu)槭裁匆?/p>

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

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

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

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

　　2、你要是想知道，LR是如何實現迭代和并發(fā)：

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

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

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

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

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

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

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