LR的響應時間與使用IE所感受時間不一致的討論
在做效能測試時，有時碰到這樣一種情況，使用效能工具LR測試出來的響應時間比實際使用IE感受到的時間要長，例如，實際使用IE開啟一個系統時只需要1~2秒，而使用LR跑一個使用者所得出的結果可能是8秒、10秒、或者更大的響應時間。
針對上述問題進行分析總結，有3種情況：
1、在執行LR場景時沒有忽略Think Time（思考時間）和記錄log的時間；
2、測試機配置不高，比如低配置的機器在執行場景工具時系統資源已滿，則造成響應時間過長。
3、實際IE感受的時間不等同於LR錄製的響應時間。
前兩中情況可以通過LR設定及提高硬體配置解決。
第三種情況，因為LR在錄製過程中，事物的響應時間
所以我們通常使用IE所感受到的時間是比用效能工具錄製時記錄的響應時間
--------
對時間的解釋：
1、DNS Resolution：瀏覽訪問一個網站的時候，一般用的是域名，需要DNS伺服器把域名解析為IP地址，這個過程就是域名解析時間。
2、Connection：解析出WebServer的IP地址後，瀏覽器請求被髮送到了一個Web Server，然後瀏覽器和Web Server 之間需要建立一個初始化的HTTP連線，伺服器端需要做兩件事：一個是接收請求，二是分配程序。建立該連線的過程就是Connection。
3、First Buffer：建立連線後，從Web Server發出第一個資料包，進過網路傳輸到客戶端，瀏覽器成功接收第一個位元組的時間就是First Buffer。
4、Receive：從瀏覽器接收第一個位元組起，直到成功收到最後一個位元組，下載完成為止。
5、Client Time：請求在客戶端瀏覽器延遲的時間。
在實際使用LR做頁面請求響應時間時，我採取的是下載頁面，清除IE快取，每次都是不同使用者瀏覽，所以對伺服器的壓力比較大，每秒的請求數居高，但是得到的responsetime確實比手動的時候大了很多，個人認為，圖片在載入過程中及CSS樣式檔案，都是同步在載入，但是對IE客戶端來說，人的視覺首先會看到圖片，然後才是樣式的出現，所以感覺上要快，因為看到的是一個動態過程，但是對LR來說，它只關心，從第一次請求到最終結束請求的時間，因此時間上會比實際操作時要長。
舉個例子，或許就是一個圖片連結，但是他載入的可能一個超級連結，但是這個連結又是用ajax來實現的，另外還帶有CSS，但是對IE端使用者來說，只要看到圖片就認為載入完畢了！
例如，我們需要衡量伺服器處理一個請求的平均響應時間。考慮，伺服器端能同時併發處理的請求數一定，當效能測試傳送的每秒請求數超過它能處理的請求數後，再到達的請求將會在伺服器系統中排隊等待，這時，整個響應時間的計時已經開始，排隊等待時間將會計入響應時間。所以，如果LR仍然持續傳送請求，可能造成接下來的請求都在等待。這時，伺服器每次處理的事務數在下降，平均響應時間在增大，造成了請求傳送越快，處理越少越慢。對於這種情況，從伺服器端出發，來考慮設定請求傳送的速度。”
悟石：“從伺服器端來看，讓每顆CPU都忙碌起來，是件好事。當壓力超過CPU能承受範圍時，認為是過載，等待佇列會越來越長，load不斷飆升。
其實LoadRunner 是以客戶端的角度來定義“響應時間”的，當客戶端請求發出去後， LoadRunner 就開始計算響應時間，一直到它收到伺服器端的響應。這個時候問題就產生了：如果此時的伺服器端的排隊佇列已滿，伺服器資源正處於忙碌的狀態，那麼該請求會駐留在伺服器的執行緒中，換句話說，這個新產生的請求並不會對伺服器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結束後，我們檢視一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，由於客戶端傳送的請求太快而導致影響了實際的測量結果，設定步長則可以緩解這一情況，這樣，應該試試設定pacing，再執行看看情況
後嘗試配置pacing為delay30s， 場景結果有所改變。需要仔細瞭解其中原理。