在場景的兩次迭代 (iteration) 之間，加入一個時間間隔（步進）
● As soon as the previous iteration ends ：在多次重複執行時，一次執行完馬上執行下一次。
● After the previous iteration ends ：在上一次執行完畢後，間隔固定的時間來執行下一次。
● At fixed intervals：不管上一次執行是否完成，達到規定的時間後就執行下一次。這個設置到底有什麼作用？爲什麼要進行這個設置?
在 LoadRunner 的運行場景中，有一個不大起眼的設置，可能經常會被很多人忽略，它就是 Pacing 。具體設置方式爲： Run-Time settings General Pacing ，這個設置的功能從字面上就很容易理解，即在場景的兩次迭代 (iteration) 之間，加入一個時間間隔（步進）。設置方法也很簡單，這裏就不贅述了，我在這裏想說明的是，這個設置到底有什麼作用？爲什麼要進行這個設置？說實話，雖然我在以前做過的一些性能測試中，偶爾會對這個步進值進行一些設置，但其實對它的真正含義和作用，我還並不十分清楚。
前段時間，我在對X銀行招聘信息系統進行性能測試的時候，發現這個值的設置對於測試的結果有着很大的影響，很遺憾當時沒有深入研究這個問題，而只是簡單地認爲它同腳本中的 thinktime 一樣只是爲了更真實地模擬實際情況而已。最近在網絡上看到一篇題爲《調整壓力測試工具》的文章，讀完之後，再用之前我的測試經歷加以印證，真有種豁然開朗的感覺。以下就將我的一些體會與大家分享：
通常我們在談到一個軟件的“性能”的時候，首先想到的就是“響應時間”和“併發用戶數”這兩個概念。我們看到的性能需求經常都是這樣定義的：
“要求系統支持 100 個併發用戶”
看到這樣的性能需求，我們往往會不假思索地就在測試場景中設置 100 個用戶，讓它們同時執行某一個測試腳本，然後觀察其操作的響應時間，我們都是這樣做的，不是嗎？我在實際實施性能測試的過程中，也往往都是這樣做的。可惜的是，我們中的大多數人很少去更深入地思考一下其中的奧妙，包括我自己。
事實上，評價一個軟件系統的性能，可以從兩個不同的視角去看待：客戶端視角和服務器視角（也有人把它叫做用戶視角和系統視角），與此相對應的，又可以引出兩個讓初學者很容易混淆的兩個概念：“併發用戶數”和“每秒請求數”。“併發用戶數”是從客戶端視角去定義的，而“每秒請求數”則是從服務器視角去定義的。
因此，上面所描述的做法的侷限性就是，它反映的僅僅是客戶端的視角。
對於這個世界上的很多事情，變換不同的角度去看它，往往可以有助於我們得到更正確的結論。現在，我們就轉換一下角度，以服務器的視角來看看性能需求應該怎麼樣定義：
“要求系統的事務處理能力達到 100 個 / 秒” ( 這裏爲了理解的方便，假定在測試腳本中的一個事務僅僅包含一次請求 )
面對以這樣方式提出的性能需求，在 LoadRunner 中，我們又該如何去設置它的併發用戶數呢？千萬不要想當然地以爲設置了 100 個併發用戶數，它就會每秒向服務器提交 100 個請求，這是兩個不同的概念，因爲 LoadRunner 模 擬客戶端向服務器發出請求，必須等待服務器對這個請求做出響應，並且客戶端收到這個響應之後，纔會重新發出新的請求，而服務器對請求的處理是需要一個時間 的。我們換個說法，對於每個虛擬用戶來說，它對服務器發出請求的頻率將依賴於服務器對這個請求的處理時間。而服務器對請求的處理時間是不可控的，如果我們 想要在測試過程中維持一個穩定的每秒請求數（ RPS ），只有一個方法，那就是通過增加併發用戶數的數量來達到這個目的。這個方法看起來似乎沒有什麼問題，如果我們在測試場景中只執行一次迭代的話。然而有經驗的朋友都會知道，實際情況並不是這樣，我們通常會對場景設置一個持續運行時間（即多次迭代），通過多個事務 (transaction) 的取樣平均值來保證測試結果的準確性。測試場景以迭代的方式進行，如果不設置步進值的話，那麼對於每個虛擬用戶來說，每一個發到服務器的請求得到響應之後，會馬上發送下一次請求。同時，我們知道， LoadRunner 是以客戶端的角度來定義“響應時間”的 ，當客戶端請求發出去後， LoadRunner 就開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：如果此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那麼該請求會駐留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載， 但很遺憾的是，該請求的計時器已經啓動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試 結束後，我們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其 實也就失去了它應有的意義。也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果。
因此，爲了解決這個問題，我們可以在每兩個請求之間插入一個間隔時間，這將會降低單個用戶啓動請求的速度。間歇會減少請求在線程中駐留的時間，從而提供更符合現實的響應時間。這就是我在文章開頭所提到的 Pacing 這個值的作用。
最後再補充一句話：雖然性能測試通常都是從客戶端活動的角度定義的，但是它們應該以服務器爲中心的視角來看待。請注意這句話，理解它很重要，只有真正理解了這句話，你纔會明白爲什麼我們一直強調做性能測試的時候要保證一個獨立、乾淨的測試環境，以及一個穩定的網絡，因爲我們希望評價的是軟件系統真正的性能，所以必須排除其它一切因素對系統性能造成的影響。
花了幾天的時間才完成這篇文章，如果它能夠幫助大家對性能測試多一些理解或者多一些思考，那就是我的榮幸了。 ^_^