Pacing時間的設置需要根據使用您系統的用戶的行為來決定。
如果您那邊的用戶在您的系統上做完一套操作后不會做下一套，則可能不需使用Pacing。
如果您那邊用戶在系統上需要不斷地做同樣的操作，比如他要反復的瀏覽或者操作一些信息，每做完一套操作后可能需要做一些確認或者是停頓，則需要添加Pacing時間。
1、步長的設置會影響虛擬用戶一次迭代中的Action之間的等待時間和該虛擬用戶上次迭代和下次迭代的等待時間，不同虛擬用戶之間的迭代等待時間是不受影響的。
2、這個設置的功能從字面上就很容易理解，即在場景的兩次迭代(iteration)之間，加入一個時間間隔（步進）。
3、通常我們在談到一個軟件的“性能”的時候，首先想到的就是“響應時間”和“並發用戶數”這兩個概念。我們看到的性能需求經常都是這樣定義的：
“要求系統支持100個並發用戶”
看到這樣的性能需求，我們往往會不假思索地就在測試場景中設置100個用戶，讓它們同時執行某一個測試腳本，然后觀察其操作的響應時間，我們都是這樣做的，不是嗎？我在實際實施性能測試的過程中，也往往都是這樣做的。可惜的是，我們中的大多數人很少去更深入地思考一下其中的奧妙，包括我自己。
事實上，評價一個軟件系統的性能，可以從兩個不同的視角去看待：客戶端視角和服務器視角（也有人把它叫做用戶視角和系統視角），與此相對應的，又可以引出兩個讓初學者很容易混淆的兩個概念：“並發用戶數”和“每秒請求數”。“並發用戶數”是從客戶端視角去定義的，而“每秒請求數”則是從服務器視角去定義的。
因此，上面所描述的做法的局限性就是，它反映的僅僅是客戶端的視角。
對於這個世界上的很多事情，變換不同的角度去看它，往往可以有助於我們得到更正確的結論。現在，我們就轉換一下角度，以服務器的視角來看看性能需求應該怎么樣定義：
“要求系統的事務處理能力達到100個/秒”(這里為了理解的方便，假定在測試腳本中的一個事務僅僅包含一次請求)
面對以這樣方式提出的性能需求，在LoadRunner中，我們又該如何去設置它的並發用戶數呢？千萬不要想當然地以為設置了100個並發用戶數，它就會每秒向服務器提交100個請求，這是兩個不同的概念，因為LoadRunner模擬客戶端向服務器發出請求，必須等待服務器對這個請求做出響應，並且客戶端收到這個響應之后，才會重新發出新的請求，而服務器對請求的處理是需要一個時間的。我們換個說法，對於每個虛擬用戶來說，它對服務器發出請求的頻率將依賴於服務器對這個請求的處理時間。而服務器對請求的處理時間是不可控的，如果我們想要在測試過程中維持一個穩定的每秒請求數（RPS），只有一個方法，那就是通過增加並發用戶數的數量來達到這個目的。這個方法看起來似乎沒有什么問題，如果我們在測試場景中只執行一次迭代的話。然而有經驗的朋友都會知道，實際情況並不是這樣，我們通常會對場景設置一個持續運行時間（即多次迭代），通過多個事務(transaction)的取樣平均值來保證測試結果的准確性。測試場景以迭代的方式進行，如果不設置步進值的話，那么對於每個虛擬用戶來說，每一個發到服務器的請求得到響應之后，會馬上發送下一次請求。同時，我們知道，LoadRunner是以客戶端的角度來定義“響應時間”的，當客戶端請求發出去后，LoadRunner就開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：如果此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那么該請求會駐留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結束后，我們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果。
因此，為了解決這個問題，我們可以在每兩個請求之間插入一個間隔時間，這將會降低單個用戶啟動請求的速度。間歇會減少請求在線程中駐留的時間，從而提供更符合現實的響應時間。這就是我在文章開頭所提到的Pacing這個值的作用。
最后再補充一句話：雖然性能測試通常都是從客戶端活動的角度定義的，但是它們應該以服務器為中心的視角來看待。請注意這句話，理解它很重要，只有真正理解了這句話，你才會明白為什么我們一直強調做性能測試的時候要保證一個獨立、干凈的測試環境，以及一個穩定的網絡，因為我們希望評價的是軟件系統真正的性能，所以必須排除其它一切因素對系統性能造成的影響。
雲層：
但是你忽略了一個真實負載中可能出現排隊的情況，而無法得到多少負載會產生排隊導致響應時間變長的真實結果！
那么你設置不合理的pacing就片面的降低了負載