1.Runtime setting的設置
*Think time
這個就不多說了，如果忽略則"響應時間"會變短，但同時對服務器的壓力增大，從而間接影響響應時間
在anlaysis里有個過濾設置，可以設置過濾掉Thinktime，沒有詳細研究過
* Pacing設置
這個是我們經常忽略的一個設置
xinqidian123在他的空間的文章里提到：
其實LoadRunner是以客戶端的角度來定義“響應時間”的，當客戶端請求發出去后，LoadRunner就 開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：如果此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那么該請求會駐 留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見 到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結 束后，我們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實 也就失去了它應有的意義。也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果，設置步長則可以緩解這一情況，這樣，應該試試設置pacing，再運行看看情況。
2.場景的設置
加載和釋放虛擬用戶的設置
如果在比較短的時間間隔加載較多的vuser，無疑會對加載過程中的服務器產生較大壓力，從而使總的平均響應時間變長
有時我們會發現一個有點費解的現象，在場景停止的最后時間，響應時間圖的曲線會呈上升狀態
在論壇里看到有同學提出這樣的疑問，有回復提到：
如果在高負載的系統中運行，會話線程執行完后一直沒有釋放的話，那么就會造成后者請求線程一直在等待前者運行線程的結束，那么響應時間自然而然的就增加了。類似於Pacing設置的說明
個人覺得，和釋放vuser的設置應該也有一定關系，希望各位來探討下
1.在看這篇文章之前我想大家首先要對LR有一定的了解，你要知道以下這些內容：
1)LR中是通過Transaction進行響應時間統計的，Transaction是一組函數，可以在測試腳本中根據我們要衡量的業務響應時間進行定義，要是大家不了解可以參見我寫的一篇關於LR事物的專題：
2)LR結果分析中給出的響應時間有：最大、平均、最小、標准差、90%幾種，另外包括一個事物平均響應時間的曲線。
3)LR的響應時間的統計是基於事物的，這些數據可以在結果分析中得到。
4)最好你對Excel中的函數不陌生
2.那么LR結果分析中如何獲得這些響應時間的呢?下面我們開始介紹：
1)首先LR以時間位移為基准收集所有事物的響應時間，收集的這些數據作為分析的基礎。
2)將上述收集的信息進行統計得到最大、平均、最小、標准差、90%的響應時間。以及畫出事物平均響應時間的曲線。
3)平均響應時間：在事物全部響應時間做平均計算;
4)最大響應時間：在事物全部響應時間中求MAX
5)最小響應時間：在事物全部響應時間中求MIN
6)標准差：在事物全部響應時間數據中做標准差運算
7)90%響應時間：將事物全部響應時間進行排序然后求90%數據中的最大值;
8)事物平均響應時間曲線，曲線中點的個數跟取樣時間(可設定)和測試運行時間相關(當然選取的數據是可以設定的，在結果分析過程中可以選擇抽取那段時間的數據);每個點數據的計算是根據：在采樣時間范圍內所有事物響應時間的平均。
3.如何驗證上述的情況是對的呢?大家可以用以下的方法：
1) 設置一個LR的測試場景，運行獲得結果數據;
2) 打開結果分析工具，獲得測試結果;
3) 然后將LR中統計的所有數據導入到Excel中進行手動分析(具體步驟不說了);
4) 通過EXCEL中的數據統計功能，統計最大、最小、平均、標准差(可以去網上查他的含義，我不想說，這是數學)、90%的響應時間，然后跟LR結果分析中給出的數據進行比較，你就能驗證你的想法。
這些東西什么用?你可以說他很有用，當然對於你也可能沒有用，而只看一個熱鬧，那么對於所有看熱鬧的人來說就當一個樂子吧，對於有用的人來說，你就來着了，具體更深的細節我們可以再討論。