LoadRunner中影響"響應時間"的設置

09-04

來自專欄性能測試5 人贊了文章

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結果分析中給出的數據進行比較，你就能驗證你的想法。