在做效能測試時，有時碰到這樣一種情況，使用效能工具lr測試出來的響應時間比實際使用ie感受到的時間要長，例如，實際使用ie開啟乙個系統時只需要1~2秒，而使用lr跑乙個使用者所得出的結果可能是8秒、10秒、或者更大的響應時間。
針對上述問題進行分析總結，有3種情況：
1、在執行lr場景時沒有忽略think time（思考時間）和記錄log的時間；
2、測試機配置不高，比如低配置的機器在執行場景工具時系統資源已滿，則造成響應時間過長。
3、實際ie感受的時間不等同於lr錄製的響應時間。
前兩中情況可以通過lr設定及提高硬體配置解決。
所以我們通常使用ie所感受到的時間是比用效能工具錄製時記錄的響應時間要少。因此，系統頁面的響應時間應以工具記錄時間為準，並在分析報告中檢視平均事物響應時間。
對時間的解釋：
2、connection：解析出webserver的ip位址後，瀏覽器請求被傳送到了乙個web server，然後瀏覽器和web server 之間需要建立乙個初始化的http連線，伺服器端需要做兩件事：乙個是接收請求，二是分配程序。建立該連線的過程就是connection。
3、first buffer：建立連線後，從web server發出第乙個資料報，進過網路傳輸到客戶端，瀏覽器成功接收第乙個位元組的時間就是first buffer。
5、client time：請求在客戶端瀏覽器延遲的時間。
舉個例子，或許就是乙個鏈結，但是他載入的可能乙個超級鏈結，但是這個鏈結又是用ajax來實現的，另外還帶有css，但是對ie端使用者來說，只要看到就認為載入完畢了！
例如，我們需要衡量伺服器處理乙個請求的平均響應時間。考慮，伺服器端能同時併發處理的請求數一定，當效能測試傳送的每秒請求數超過它能處理的請求數後，再到達的請求將會在伺服器系統中排隊等待，這時，整個響應時間的計時已經開始，排隊等待時間將會計入響應時間。所以，如果lr仍然持續傳送請求，可能造成接下來的請求都在等待。這時，伺服器每次處理的事務數在下降，平均響應時間在增大，造成了請求傳送越快，處理越少越慢。
對於這種情況，從伺服器端出發，來考慮設定請求傳送的速度。」
悟石：「從伺服器端來看，讓每顆cpu都忙碌起來，是件好事。當壓力超過cpu能承受範圍時，認為是過載，等待佇列會越來越長，load不斷飆公升。
其實loadrunner 是以客戶端的角度來定義「響應時間」的，當客戶端請求發出去後， loadrunner 就開始計算響應時間，一直到它收到伺服器端的響應。這個時候問題就產生了：如果此時的伺服器端的排隊佇列已滿，伺服器資源正處於忙碌的狀態，那麼該請求會駐留在伺服器的執行緒中，換句話說，這個新產生的請求並不會對伺服器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結束後，我們檢視一下結果，就會發現這樣乙個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，由於客戶端傳送的請求太快而導致影響了實際的測量結果，設定步長則可以緩解這一情況，這樣，應該試試設定pacing，再執行看看情況
後嘗試配置pacing為delay30s， 場景結果有所改變。需要仔細了解其中原理。
解決crontab時間和系統時間不一致的問題
今天發現有一台機器，同樣乙個指令碼，在shell裡呼叫獲取的時間和在crontab裡呼叫獲取的時間差幾個時區，經過分析，發現問題在於 etc localtime這個檔案指向的時區檔案和別的機器不一樣 刪除重建該軟連線之後問題解決 root rwsaa193 ls al etc localtime l...
前端展示的時間資料庫的時間不一致
這幾天遇到乙個巨大的坑啊，資料存的時間是2點，但是前端頁面顯示的時間變成了16點，差了14個小時。描述一下專案背景，服務在美國，專案是墨西哥專案，資料庫的時間和伺服器的時間都已經設定成了墨西哥時區，但是還是不對。中間問過專案的大佬，大佬給的意見是連線資料的url上在設定時區 但是前端頁面還是展示不正...
檔案屬性中的建立時間與新建時間不一致的問題
我在做測試的時候出現乙個問題，我之前建立了乙個檔案，然後刪除，最後在較短的時間內，建立同樣名字的檔案，發現檔案的建立的時間是與原先我刪除的時間一樣。我多次嘗試了一下還是同樣的結論。檔案的建立的時間與新建時間不一定相同 原理，需要進一步理解 用了許多方式以後，發現我們可以利用下面的 對檔案的建立時間進...