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