LoadRunner 壓測場景制定以及報告分析

這里，我們利用 LoadRunner 來制定場景，且以測試 tps 值為導向，主要介紹手工場景

　　單服務器的業務請求處理能力 tps 值在 10~200 是合理的；如果是訪問單接口不走關系型數據庫的，訪問的是 redis （內存里面讀）那么 tps 在 1000~2000 左右是合理的

　　單負載機的最大並發多少？不管是 LR 和 JMeter，10~4000 是合理的

如果要測試響應時間或者是說並發，是要有前提條件的：比如說並發為 100 的響應時間為 XX，響應時間為 1 s 支持的最大並發量為 XX。所以說 tps 值是一個最普遍的值，1s 處理的事務數。

前提：准備好沒問題的腳本以及數據，負載機等

 

進入壓測場景的方式有兩種，這里，我們示范兩種方式的進入手工設定場景
1、直接進入 Run Load Tests

 

2、從腳本顯示頁進入

 

Controller-Scenario

性能測試有三個場景需要測試：單場景，混合場景，穩定性測試場景

Design

Scenario Groups 基本設置

　　這一部分主要的功能是選擇進行壓測的腳本

1. Group Name　　## 腳本名稱
2. Script Path　　## 腳本路徑
3. Quantity　　## 最大 Vu 數
4. Load Generators　　## 腳本壓測選擇的負載機

 

如果我們這里只選擇一個腳本，那么就是單場景壓測，如果需要跑混合場景，那么就得增加 Group

修改頁面如下：Group Name不重要，可以手動修改，執行的是 Script Path 內的腳本

 

如果我們選擇 1 個以上的腳本進行並發，那么就是混合場景：

 

修改腳本的 Quantity

Quatity這里比較特殊，不能直接修改，我們需要選中腳本，點擊 "Virtual Users" ，再去選擇添加的虛擬戶數

 

並且可以針對每個 Vu ，選擇不同的負載機

 

分布式負載設置

那么，怎么添加負載機，做分布式負載呢？（兩種方式）

 

添加好負載機還得將腳本連接好負載機：

　　負載機不需要安裝完整的 LoadRunner，只需要安裝 LoadRunner 的 Generator 模塊，並且正在運行

 

連接好負載機后，如果負載機在 Windows 上，會有個小雲朵的圖標，代表連接上了該負載機

 

壓測內修改腳本以及更新 Run-time Settngs

並且可以修改 RunTime-Setting / Scripts：修改完腳本或者 RunTime-Setting 需要點擊 "Refresh"，選擇更新腳本或者是 setting

 

這樣第一部分的 Senario Group 就基本設置完成。

 

Scenario Schedule

A.   定義方案schedule

在 Scenario Schedule面板中,選擇一個方案schedule,或通過點擊New Schedule定義一個新的方案

 

 

group：多個腳本之間按照獨立設置模式跑，各個腳本可以單獨設置虛擬用戶、運行時間等
scenario：多個腳本之間按照相同的模式跑，將總的虛擬用戶數按照一定的比例分配給各個腳本

定義schedule:

• 新建schedule：點擊新建按鈕(可選)
• 重命名schedule:在 Schedule Name 輸入新的名字並點擊Save New Name(可選).
• 選擇schedule類型,Schedule by: Scenario 或 Group.
• 選擇運行模式Run mode: Real-world 或Basic

說明:

　　1．對所有schedule默認的運行模式都是Real-word.你可以改變缺省模式為Basic。Tools > Options > Execution tab

 

2. Schedule by Scenario和Group的區別

Real-world Schedule和Basic schedule的區別：根據官方文檔，這兩種模式下，場景中的每個虛擬用戶組(可看成是每個腳本)都會按照它們自己的Run-Time settings中的設置運行。區別在於可模擬的操作不一樣：

Schedule by:Scenario

Basic Schedule：可以定義每次運行多少用戶，場景持續運行多久

Real-world Schedule:同Basic schedule，除此之外，還可以設置每次停止多少個用戶。

 

Schedule by:Group(該設置在百分比模式下不可見)

Basic schedule：可以定義什么時候開始運行虛擬用戶組(Group和Scenario的主要區別)，每次運行多少個虛擬用戶，場景持續運行多久

Real-world Schedule:同Basic Schedule，除此之外，還可以設置每次停止多少個虛擬用戶。

 

雙擊Group Schedule下的Start Group Action，打開Start Group策略，設置腳本在手工場景下的Group模式中如何開始運行

 

B.   為schedule定義action(Global schedule)

Actions表格展示了默認的與步驟2選擇的shedule對應的actions。

 

Schedule Actions.

一個場景schedule包含了一系列actions，指導場景什么時候運行Vuser group，怎么初始化虛擬用戶，合適開始和停止虛擬用戶，及運行一個action要花的時間。

 

注意:腳本中帶集合點會妨礙場景方案的運行。如果有包含集合點，場景可能不會按照你設定的方案運行。

 

說明：

1)   Start Group

　　定義何時開始運行Vuser Group

1、Start immediately after the scenario begins(缺省)

　　LoadRunner在場景一運行就開始運行Vuser Group

2、Start <00:00:00> (HH:MM:SS) after the scenario begins

　　場景運行后，LoadRunner等待指定的時間后開始運行Vuser group.

3、Start when group finishes

　　指定Vuser group運行完成后，LoadRunner馬上開始運行該Vuser group.

注意:Start Group僅在group schedule類型中可用，而且總是作為第一個action出現.

 

2)   Initialize

　　指導LoadRunner准備Vusers，以便於他們處於准備運行狀態.

1、Initialize all Vusers simultaneously

　　在LoadRunner在運行vuser前初始化所有Vusers.

注意：選擇該設置可能會導致運行出錯：error-27796 failed to connect to server

2、Initialize XX Vusers every <00:00:00> (HH:MM:SS)

　　LoadRunner在運行vuser前，根據指定的時間間隔，逐漸初始指定數量的Vuser,

3、Initialize each Vuser just before it runs(Default)

　　LoadRunner在運行它們前初始化每一個Vuser

注意：當Wait for all groups to initialize選項被選中時，必須等所有的Vuser group完成對虛擬用戶的初始化后才運行

該選項對於group scenario不可用

 

3)   Start Vusers

指示loadRunner開始運行Vusers。

1、Start XX Vusers: Simultaneously(Default)

　　指定LoadRunner運行場景的虛擬用戶總數

2、Start XX Vusers: YY Vusers every <00:00:00> (HH:MM:SS)

　　LoadRunner按指定的時間間隔，逐步運行指定數量XX個Vusers，也就是說LoadRunner運行指定數量的一組Vusers,並且等待指定時間后運行指定下一組Vuser.

3、點擊Previous 或Next可切換其它要編輯的action.

 

注意:

1.當且僅當Vuser處於Ready狀態時，LoadRunner才開始運行Vuser.

2.Basic運行模式下默認運行所有用戶

 

4)   Duration

持續時間

Real-world schedule

 

Basic schedule

1、Run until completion

　　按Controller中Run-time settings -> logic中的迭代次數進行迭代，迭代完成則停止運行。

2、Run for x days and xx:xx:xx

　　忽略Run-time settings -> logic中設置的迭代次數，重復迭代運行腳本的action，直到時間結束為止， 也就是說，此處設置的持續時間的優先級高，

也就是說：

1. 即使你指定了迭代次數，但是運行時間沒有結束之前，還是會一直迭代，所以實際迭代次數可能大於你設置的迭代次數；
2. 還有一種情況是，迭代次數還沒完，但是運行時間已經到了，此時會將當前執行的Action執行完，停止迭代，此種情況下實際迭代次數小於你設置的迭代次數。

3、Run indefinitely

　　無限運行

C.   從Actions表格中添加一個action到schedule

步驟1：打開添加Action對話框

方法1、在指定action后插入一個action，選擇這個action並點擊Add Action After

 

方法2、在最后一個action后添加一個action，在Action表格中雙擊最后一行

步驟2：在Add Action對話框中，定義新的action

注意：這里的Start Vuser數量的設置，會改變上方的組或腳本的虛擬用戶數量Quatity

 

步驟3：點擊Apply.

 

步驟4：繼續添加另一個action，點擊Add Another Action並重復步驟2，3

 

 

Schedule by：Scenario

　　如果是測試 tps ，Start Vu 和 Stop Vu直接選 "Simultaneously" 即可，因為測試 tps 是先看 1 個 Vu，是多少；2 個 Vu，是多少……等到 tps 上升值很小，就可以考慮用熱啟動方式去驗證一下，順便截圖寫報告

 1、Initialize

　　初始化：把用戶的進程或者是線程准備好，但是並不運行

　　我們這里可以極端點，直接選第一個

 

2、Start Vuers——設置啟動用戶

　　這里可以設置 Vu ，指的是這個壓測場景所有的用戶，比如說我們設置 100，上面的也會被更改掉

　　如果選擇 "Simultaneously"，代表所有的 Vu 同時啟動，效果如圖示（冷啟動）

　　如果 Vu 太多，建議還是這種方式直接起來，時間太寶貴，等？誰等？

 

 

　　我們也可以選擇讓 Vu 階段性上升，同時設置其上升的時間，比如說，每 3 min 增加 5 個 Vu ，效果如圖（熱啟動）

 

3、Duration——持續時間

　　很容易理解，就是指到達最大 Vu ，繼續保持的時間多長，我們如果測試 tps ，這里設置 10~15 min就行

 

4、Stop Vusers

　　和 Start Vuers 一樣，代表關閉的線程/Vu，這里直接 Simultaneously 就好了，直接退

 

Schedule by：Group

　　Group 模式，我們加進一個其他腳本，我們發現 Group 相對於 Scenario 多了一個：Start Group

　　這個代表可以多場景分組運行

 

例如，我們讓兩個場景排順序進行：

 

而且，Group 模式下，每個腳本的 Vu 是可以自己設定的：

 

Global-Oriented Scenario——面向目標的場景設計

 

不同的是，面向目標的負載機需要手動添加，即使是本機的

重點說下下面的區別：

 

 我們進入 "Edit Scenario Global" 看看，可以看到目標分為五種

目標可以分為五種

1. VUser
2. pages per minute
3. transaction per second
4. hits per second
5. trasaction response time

Virtual Users Goal:

　　如果需要測試多少人可以同時運行Web應用，那么推薦定義Virtual Users Goal. 運行定義該目標類型的場景和運行Manual 類型的場景類似。

Hits per Second:

　　如果想測試Web Server的真正實力，推薦定義目標類型為：Hits per Second,Pages per Minute 或者Transactions per Second,這些類型都需要制定一個虛擬用戶的最大值和最小值的范圍

Transactions Response Time

　　如果想知道在多少用戶並發訪問網站時，事務的響應時間達到性能指標說明書中規定響應時間的最大值，那么推薦使用Transactions Response Time類型，指定需要測試的事務的名稱，虛擬用戶數量的最大值和最小值，還有預先定義好的事務的響應時間。

 

我們這里主要看倆：Transaction Per Second & Transactions Response Time

這里，我們用 tps 為例，解釋下參數，但是目標為 tps 很少

 

目標為響應時間支持的用戶數，是我們的一個指標。比如我們設置響應時間為 2 s，用戶數在 1~150 之間進行嘗試，嘗試時間為 30 min

 

 

Run

 Scenario Groups

這里的狀態指的是各 Vu 的狀態，Vu 其實對應的就是負載機的進程/線程

Vu 狀態：

• Down:沒有運行
• Pending:掛起
• Init:初始化
• Ready:准備就緒
• Run:正在運行
• Rendezvous:正在集結
• Passed:運行通過
• Failed:運行失敗
• Error:出現故障
• Gradual Exting:逐一退出
• Exiting:退出
• Stopped:停止運行

場景控制：

• Star Scenario:運行場景
• Stop:強制停止運行場景
• Rest:將所有選項恢復到默認值
• Vuses:管理虛擬用戶
• Run/Stop/ Vuses:啟動和停止部分虛擬用戶

場景狀態：

• Runing Vuses:正在運行的用戶數
• Elapsed Time:場景已經運行的時間
• Hits/second:每秒鍾點擊數
• Passed Transactions:通過的事務數（總事務）
• Failed Transactions:未通過的事務數
• Errors:出現的錯誤數（失敗率不能大於 1%，視公司標准而定。只能將服務器的錯誤計算進去，不能將負載機的錯誤計算進去）

注意：Failed Transactions指的是由於事務本身沒有缺陷，但由於並發數較多等原因沒有連通，而Errors是指事務運行期間產生的缺陷，一般比較嚴重

 

接下來是幾個視圖：常用的視圖如下

1. Runtime Graphs(運行時圖表)： 顯示運行的虛擬用戶、運行時發生的錯誤、用戶自定義數據點信息。
2. Transaction Graphs(交易情況圖表): 顯示交易響應時間以及每秒成功交易的數量、百分比等。
3. Web Resource Graphse(網絡資源情況圖表): 顯示每少點擊量、吞吐量、每少連接數量等。
4. System Resource Graphs(系統資源情況圖表)：顯示Windows、UNIX等不同系統的資源情況等。
5. Network Graphs(網絡情況圖表)：顯示網絡延遲信息。
6. Firewalls(防火牆情況圖表)： 目前只支持某品牌防火牆信息，一般場景基本不會用到。
7. Web server Resource Graphs(網絡服務器情況圖表): 顯示多種網站服務器的性能信息，如apache.
8. Web application server Graphs(網絡應用服務器情況圖表)：顯示多種應用服務器的性能信息，如Weblogic。
9. Databases server resource graphs(數據庫情況圖表): 顯示4種主流數據庫的性能信息，如DB2、Oracle、SQLServr等，不支持mysql。
10. Streaming Media（流媒體情況圖表）：顯示windows media server和Real server以及相應客戶端的性能信息。
11. 其他類型圖表:中間件、CRM/ERP等。

 

問題：不光是出現了腳本內的事務，還出現了兩個無關事務。

解決：把定義每個 action 為事務的選項取消勾選

 

這里要注意，標准方差不要太大，穩定的話，取這里的平均值就好，如果標准方差 > 8 的話，就看 Analysis 視圖內的 90% percent 的響應時間

 

tps 的 max ，min，Std 都為 NA？這個是正常的，只統計 avg 和 last

 

Analysis

 

打開方式：

 

Summary Report

 

還可以加 Graph，例如我們加一個 tps 的

 

Merge：

LoadRunner 的分析頁面，圖標是可以合並的，假設我們把 RT 和 Vu 表進行合並，就可以知道在哪個用戶節點對應的 RT 是多少，更直觀地分析性能拐點

操作：

結果：

 

另外可以截取時間段的結果視圖：

 

對分析有幫助的：

Web Page Diagnostics 模塊，但是我這里不知道為啥沒有顯示

 

但是我是打開了該功能的：

 

 

這玩意的有一個試圖叫：Page Download Time Breakdown 是用來分析，我們的時間是花在哪兒了

有以下幾個玩意：

DNS Resolution Time ：DNS 的解析時間，一般在毫秒級

Connection Time：客戶端與服務器進行 tcp/ip 連接所花費的時間，這個長有可能是 tcp/ip 連接數滿了，或者說是網絡慢

SSL Handshake Time ：SSL 建立安全協議的時間，一般在毫秒級

FTP時間

First Buffer Time：服務器處理這個請求以及開始發送第一幀數據的時間，可以理解為服務器的真正業務處理的時間

Receive Time：服務器向客戶端發送數據，接收所花費的時間

Client Time：客戶端排隊的時間

  一、啟用網頁細分圖

首先在Controller場景設計運行之前，需要在菜單欄中設置Diagnostics->Configuration->-->Web PageDiagnostics中置為Enabled,即該項前打對鈎。如果不選中，則場景跑完后，分析結果中網頁細分圖沒有數據。如圖：

 

場景運行完后，會分析結果，在HP LoadRunner Analysis 中點擊Graph -->Add NewGraph 打開一個新曲線圖，open a new Graph ;首先將該曲線圖中的右上角的Display only graphscontaining data不選中，然后點擊Web Page Diagnostics前的+號，選中Web PageDiagnostics，點擊曲線圖下方的按鈕Open Graph即可以將網頁細分圖調出。

 

二、網頁細分圖介紹

Web Page Diagnostics （以下簡稱WPD），這是LR Analysis中非常重要的一塊，搞清楚這部分的內容會讓你少走很多彎路，很多環境問題都可以通過它來定位，比如客戶端，網絡。通過它可以你可以比較好的來定位是環境的問題還是應用本身的問題，當然更重要的是Web頁面本身的問題。

Web Page Diagnostics：頁面診斷圖，也叫頁面分解總圖

“頁面分解”顯示某一具體事務在測試過程的響應情況，進而分析相關的事務運行是否正常。

此視圖下面的文件結構大體上與scripts中actions/transaction/web_url(or submit_form_request)等一系列客戶端請求 這三層體系結構類似。

 

Transactions是組成Web Page Diagnostics視圖最基本的單元。用戶可以通過右鍵選中Transaction，然后進入Web Page Diagnostics for Transaction界面，對此事務下面的頁面進行分析。在這里有二點需要說明：

1） 如果Transaction結構多於一個層次，比如Action/Load_home_page,則用戶只允許進入到子級目錄Load_home_page，即使用戶選中Action系統也會自動跳轉到下級目錄。

2） 對於事務下面的頁面請求，LR提供的操作是Break down, 也可以進行View page in Browser.

 

Web Page Diagnostics視圖可以按下面四種方式進行進一步細分：

• Download Time Breaddown（下載時間細分）
• Component Breakdown(Over Time)（組件細分(隨時間變化)）
• Download Time Breakdown(Over Time)（下載時間細分(隨時間變化)）
• Time to First Buffer Breakdown(Over Time)（第一次緩沖時間細分(隨時間變化)）

下面分別說下網頁細分圖各圖表的功能：

網頁細分圖，總共有8個圖表，分別為：

1. 頁面分解圖總（web page Diagnostics）、
2. 頁面組件細分圖（page comporment breakdown）、
3. 頁面組件細分圖（隨時間變化）（page comportment breakdown over time）、
4. 頁面下載時間細分圖（page download time breakdown）、
5. 頁面下載時間細分圖（隨時間變化）（page download time breakdown over time）、
6. 第一次緩沖時間細分圖（time to first buffer breakdown）、
7. 第一次緩沖時間細分圖（隨時間變化）（time to first buffer breaddown over time）、
8. 已下載組件大小圖（Downloaded Component Size）[KB]。

Web Page Diagnostics總圖以transaction分析為主，兼顧頁面的初步分析。

1、 頁面組件細分圖（page comporment breakdown）：顯示每個網頁及其組件的平均下載時間（以秒為單位），查看所選擇頁面中哪個元素所占的平均下載時間最長。

2、 頁面組件細分圖（隨時間變化）（page comportment breakdown over time）：此圖適合在客戶端下載組件較多時的頁面分析，通過分析下載時間發現哪些組件不穩定或比較耗時，它是隨整個場景運行的時間來變化的。

3、 頁面下載時間細分圖（page download time breakdown）：頁面下載時間細分圖根據DNS解析時間、連接時間、第一次緩沖時間、SSL握手時間、接收時間、FTP驗證時間、客戶端時間和錯誤時間對每個組件進行分析的。它可以確認在網頁下載時期，響應時間緩慢是由網絡錯誤引起，還是由服務器錯誤引起。

4、頁面下載時間細分圖（隨時間變化）（page download time breakdown over time）：顯示選定網頁下載時間細分，從中能看到頁面各個元素在壓力測試過程中的下載情況。如果某個頁面打開速度慢，通過對此圖分析，可以清楚地看到打開該頁面的時間主要在什么地方，針對此問題進行優化。

5、 第一次緩沖時間細分圖（time to first buffer breakdown）：指成功收到從web服務器返回的第一次緩沖之前的這一段時間內，每個頁面組件的相關服務器和網絡時間（以秒為單位）；

      此圖對分析頁面的時間很重要，不僅能分析出哪個頁面耗費時間較長，而且能分析出之所以耗時是網絡問題還是服務器問題。若server time明顯大於net work time,並且是其幾倍，此時服務器性能是問題關鍵。

       First Buffer Time時間分割為Network Time和Server Time。其中，網絡時間（network time）為從客戶端發送第一個HTTP請求那一刻直到收到服務端的應答報文（ACK）確認為止所經過的平均時間。服務器時間（server time）是指客戶端從收到初始HTTP請求確認直到成功收到來自web服務器的第一次緩沖為止所經過的平均時間。  （后面詳細介紹網絡時間和服務器時間）

6、 第一次緩沖時間細分圖（隨時間變化）（time to first buffer breaddown over time）：不同頁面在任一時間點的Network TIme 和Server Timef分布曲線圖；第一次緩沖時間是在客戶端與服務器建立連接后，從服務器發送第一個數據包開始計時，數據經過網絡傳送到客戶端后，再到瀏覽器收到第一個緩沖數據所用的時間。（圖中，用兩種顏色來區分服務器和網絡各自所用的時間，以確認是服務器問題還是網絡問題，此圖非常有用！）

7、已下載組件大小圖（Downloaded Component Size）[KB]：頁面中每個元素的大小（KB）

 

三、頁面細分圖分析

這里只對頁面細分圖進一步分析的思路進行梳理，有些圖只是拿來參考，並不需要進一步分析的。

1、 首先打開頁面分解總圖（Web Page Diagnostics），在左邊Breakdown Tree下，列出了腳本中添加的所有事務名稱，通常來說，我們主要關注需要並發的系統業務部分，來看login部分，下載時間（Download Time）中，主要由兩個頁面導致，其中Receive部分占用的時間最長。（Component部分不在這里看，因為在這里看不夠直觀）

2、接着打開頁面組件細分圖（Page Component Breakdown），找出所選擇頁面中哪個元素所占的平均下載時間較多，其實就上面的兩個，只不過這里是用餅圖來展示比較直觀。

 

3、 然后打開頁面下載時間細分圖（page Download Time Breakdown），根據DNS解析時間、連接時間、第一次緩沖時間、SSL握手時間、接收時間、FTP驗證時間、客戶端時間和錯誤時間的組成在所選擇的頁面上的分布情況，確定這個頁面下載時間較長的響應時間是由網絡錯誤引起，還是服務器錯誤引起的，如圖1，Receive Time時間最長，初始判斷是網絡問題引起的，但也有可能是瀏覽器請求的問題，再看頁面下載細分隨時間分布圖2，在整個login場景中該頁面元素一直在下載？這極有可能是網絡問題了。另外一點，若頁面緩存做得好，是不會一直下載的吧。

很多時候，你可以根據DNS,Connection,Receive來看出是否存在網絡問題，根據Client來判斷是否存在客戶端問題。

圖1

圖2

4、 最后打開一個非常重要的圖，即第一次緩沖時間細分圖（Time to First Buffer Breakdown），第一次緩沖時間細分圖進行對比結果是否一致，因為第一次緩沖時間細分圖也是可以確定該頁面的響應時間是由網絡錯誤引起，還是服務器錯誤引起。由此圖，可以看到，大部分的時間在Network Time。

注意;當網絡狀況不好的時候，server time很可能包括網絡時間，因為很多頁面元素比較小（小於4k的樣子），在First Buffer就完成傳輸，所以一定要注意分析。