LoadRunner效能測試工具---（三）測試結果樣例分析

前言：

    接觸效能測試一年多了，在機房也為多個系統做過負載和壓力測試，還原了上百人的測試操作，但是對於LR測試結果的分析一直都是一個瓶頸，偶然機會讓我遇到了這篇文章，一名專業測試人員的系列部落格，讓我對於效能測試的理解又深入了一個層次，在此分享給大家。

    系列部落格地址：http://www.51testing.com/?uid-562021-action-spacelist-type-blog-itemtypeid-26819

原文：

    LoadRunner效能測試結果分析是個複雜的過程，通常可以從結果摘要、併發數、平均事務響應時間、每秒點選數、業務成功率、系統資源、網頁細分圖、Web伺服器資源、資料庫伺服器資源等幾個方面分析，如圖1- 1所示。效能測試結果分析的一個重要的原則是以效能測試的需求指標為導向。我們回顧一下本次效能測試的目的，正如 所列的指標，本次測試的要求是驗證在30分鐘內完成2000次使用者登入系統，然後進行考勤業務，最後退出，在業務操作過程中頁面的響應時間不超過3秒，並且伺服器的CPU使用率、記憶體使用率分別不超過75%、70%，那麼按照所示的流程，我們開始分析，看看本次測試是否達到了預期的效能指標，其中又有哪些效能隱患，該如何解決。

                                                                                      

                                 圖1- 1效能測試結果分析流程圖

 結果摘要

　　LoadRunner進行場景測試結果收集後，首先顯示的該結果的一個摘要資訊，如圖1- 2所示。概要中列出了場景執行情況、“Statistics Summary（統計資訊摘要）”、“Transaction Summary（事務摘要）”以及“HTTP Responses Summary（HTTP響應摘要）”等。以簡要的資訊列出本次測試結果。

                 

                             圖1- 2效能測試結果摘要圖

 場景執行情況

    該部分給出了本次測試場景的名稱、結果存放路徑及場景的持續時間，如圖5- 3所示。從該圖我們知道，本次測試從15:58:40開始，到16:29:42結束，共歷時31分2秒。與我們場景執行計劃中設計的時間基本吻合。

                     

                          圖1- 3場景執行情況描述圖

 Statistics Summary（統計資訊摘要）

    該部分給出了場景執行結束後併發數、總吞吐量、平均每秒吞吐量、總請求數、平均每秒請求數的統計值，如圖5- 4所示。從該圖我們得知，本次測試執行的最大併發數為7，總吞吐量為842,037,409位元組，平均每秒的吞吐量為451,979位元組，總的請求數為211,974，平均每秒的請求為113.781，對於吞吐量，單位時間內吞吐量越大，說明伺服器的處理能越好，而請求數僅表示客戶端向伺服器發出的請求數，與吞吐量一般是成正比關係。

                            

                                                       圖1- 4統計資訊摘要圖

 Transaction Summary（事務摘要）

    該部分給出了場景執行結束後相關Action的平均響應時間、通過率等情況，如圖1- 5所示。從該圖我們得到每個Action的平均響應時間與業務成功率。

    注意：

                    

                        圖1- 5事務摘要圖

 HTTP Responses Summary（HTTP響應摘要）

    該部分顯示在場景執行過程中，每次HTTP請求發出去的狀態，是成功還是失敗，都在這裡體現，如圖5- 6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發出了211974次請求（與“統計資訊摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”則有2163，說明在本次過程中，經過發出的請求大部分都能正確響應了，但還是有部分失敗了，但未影響測試結果，“HTTP 200”表示請求被正確響應，而“HTTP 404”表示檔案或者目錄未能找到。有朋友可能會問，這裡出現了404的錯誤，為什麼結果還都通過了。出現這樣問題的原因是指令碼有些頁面的請求內容並非關鍵點，比如可能請求先前的cookie資訊，如果沒有就重新獲取，所以不會影響最終的測試結果。

         

                               圖1- 6 HTTP響應摘要

    常用的HTTP狀態程式碼如下：

401.2 未經授權: 訪問由於伺服器配置傾向使用替代身份驗證方法而被拒絕。

401.3 未經授權：訪問由於 ACL 對所請求資源的設定被拒絕。

401.4 未經授權：Web 伺服器上安裝的篩選器授權失敗。

401.5 未經授權：ISAPI/CGI 應用程式授權失敗。

401.7 未經授權：由於 Web 伺服器上的 URL 授權策略而拒絕訪問。

403 禁止訪問：訪問被拒絕。

403.1 禁止訪問：執行訪問被拒絕。

403.2 禁止訪問：讀取訪問被拒絕。

403.3 禁止訪問：寫入訪問被拒絕。

403.4 禁止訪問：需要使用 SSL 檢視該資源。

403.5 禁止訪問：需要使用 SSL 128 檢視該資源。

403.6 禁止訪問：客戶端的 IP 地址被拒絕。

403.7 禁止訪問：需要 SSL 客戶端證書。

403.8 禁止訪問：客戶端的 DNS 名稱被拒絕。

403.9 禁止訪問：太多客戶端試圖連線到 Web 伺服器。

403.10 禁止訪問：Web 伺服器配置為拒絕執行訪問。

403.11 禁止訪問：密碼已更改。

403.12 禁止訪問：伺服器證書對映器拒絕了客戶端證書訪問。

403.13 禁止訪問：客戶端證書已在 Web 伺服器上吊銷。

403.14 禁止訪問：在 Web 伺服器上已拒絕目錄列表。

403.15 禁止訪問：Web 伺服器已超過客戶端訪問許可證限制。

403.16 禁止訪問：客戶端證書格式錯誤或未被 Web 伺服器信任。

403.17 禁止訪問：客戶端證書已經到期或者尚未生效。

403.18 禁止訪問：無法在當前應用程式池中執行請求的 URL。

403.19 禁止訪問：無法在該應用程式池中為客戶端執行 CGI。

403.20 禁止訪問：Passport 登入失敗。

404 找不到檔案或目錄。

404.1 檔案或目錄未找到：網站無法在所請求的埠訪問。

404.2 檔案或目錄無法找到：鎖定策略禁止該請求。

404.3 檔案或目錄無法找到：MIME 對映策略禁止該請求。

405 用於訪問該頁的 HTTP 動作未被許可。

406 客戶端瀏覽器不接受所請求頁面的 MIME 型別。

407 Web 伺服器需要初始的代理驗證。

410 檔案已刪除。

412 客戶端設定的前提條件在 Web 伺服器上評估時失敗。

414 請求 URL 太大，因此在 Web 伺服器上不接受該 URL。

500 伺服器內部錯誤。

500.11 伺服器錯誤：Web 伺服器上的應用程式正在關閉。

500.12 伺服器錯誤：Web 伺服器上的應用程式正在重新啟動。

500.13 伺服器錯誤：Web 伺服器太忙。

500.14 伺服器錯誤：伺服器上的無效應用程式配置。

500.15 伺服器錯誤：不允許直接請求 GLOBAL.ASA。

500.16 伺服器錯誤：UNC 授權憑據不正確。

500.17 伺服器錯誤：URL 授權儲存無法找到。

500.18 伺服器錯誤：URL 授權儲存無法開啟。

500.19 伺服器錯誤：該檔案的資料在配置資料庫中配置不正確。

500.20 伺服器錯誤：URL 授權域無法找到。

500 100 內部伺服器錯誤：ASP 錯誤。

501 標題值指定的配置沒有執行。

502 Web 伺服器作為閘道器或代理伺服器時收到無效的響應。

• 併發數分析

　　“Running Vusers（執行的併發數）”顯示了在場景執行過程中併發數的執行情況。它們顯示Vuser的狀態、完成指令碼的Vuser的數量以及集合統計資訊，將這些圖與事務圖結合使用可以確定Vuser的數量對事務響應時間產生的影響。圖1- 7顯示了在OA系統考勤業務效能測試過程中Vusers執行情況，從圖中我們可以看到，Vusers的執行趨勢與我們場景執行計劃中的設定是一樣，表明在場景執行過程中，Vusers是按照我們預期的設定執行的，沒有Vuser出現執行錯誤，這樣從另一個側面說明我們的引數化設定是正確的，因為使用唯一數進行引數化設定，如果設定不正確，將會導致Vuser執行錯誤。在指令碼中我們加入了這樣一段程式碼：

if (atoi(lr_eval_string("{num}")) > 0){

lr_output_message("登入成功，繼續執行.");

}

else{

lr_error_message("登入失敗，退出測試");

return -1;

}

    上述程式碼的意思是說，如果登入失敗了，就退出指令碼的迭代，那麼什麼原因可能會導致登入失敗呢？就是我們前面引數化的設定，一旦Vuser分配不到正確的登入賬號，就可能導致登入失敗，從而引起Vuser停止執行。所以，從圖5- 7的表現，可以認為引數化是沒有問題的。

            

                               圖1- 7執行的併發數圖

    測試指令碼中我們還使用了集合點，那麼這裡還可以看看集合點在場景執行過程中的表現，點選左邊的“New Graph”，出現圖5- 8，展開“Vusers”前的加號，雙擊“Rendezvous”，出現集合點的圖形後，點選【Close】，關閉新增新圖介面。

                          

                              圖1- 8新增集合點統計圖

    集合點的圖形如圖1- 9所示，從圖中可以看到，所有使用者到達集合點後，立刻就釋放了。與之前設定的集合點策略設定“所有執行使用者到達後釋放“是一致的。假設這樣的一種情況，Running的Vusers有10個，集合點策略設定是“所有執行使用者到達後釋放”，而集合點圖形顯示的最大釋放Vusers是7個，那麼就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應超時了，可以結合平均事務響應時間再詳細分析原因。

           

                           圖1- 9集合點狀態圖

    我們本次測試Running Vusers與集合點是一致，說明整個場景執行過程中，併發數使用者的執行正確，OA系統測試伺服器能夠應付7個併發使用者的業務操作。

• 響應時間

    在效能測試要求中我們知道，有一項指標是要求登入、考勤業務操作的頁面響應時間不超過3秒，那麼本次測試是否達到了這個要求呢？我們先來看“Average Transaction Response Time（平均事務響應時間圖）”（圖1- 10），這張圖是平均事務響應時間與結果摘要中的“Transaction Summary”合成的。

            

                             圖1- 10平均事務響應時間圖

    從圖形下部我們可以看到，登入部分對應的Action是“submit_login”，考勤業務提交對應的Action是“submit_sign”，他們的“Average Time（平均響應時間為）”分別是4.425秒與0.848秒，從這兩個數值來看，考勤業務的事務響應時間0.848秒小於預期的3秒，達到了要求，而登入是4.425秒，大於預期的3秒，不符合要求。這樣的結果是不正確的，因為在統計的登入業務的時候，我們沒有去除思考時間，所以，登入功能的實際事務時間應該是4.425秒-3秒=1.425秒，小於預期的3秒，故登入業務的事務響應時間也達到了我們的要求。在平時的效能測試活動中，統計結果的時候需要去掉思考時間，加上思考時間是為了真實的模擬使用者環境，統計結果中除去思考時間是為了更真實的反映伺服器的處理能力，兩者並不矛盾。

    看完了“Average Time”，我們再看“90 Percent Time”，這個時間從某種程度來說，更準確衡量了測試過程中各個事務的真實情況，表示90%的事務，伺服器的響應都維持在某個值附近，“Average Time”值對於平均事務響應時間變動趨勢很大的情況統計就不準確了，比如有三個時間：1秒、5秒、12秒，則平均時間為6秒，而另外一種情況：5秒、6秒、7秒，平均時間也為6秒，顯然第二種比第一種要穩定多了。所以，我們在檢視平均事務響應時間的時候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽上忽下的波動情況，取“Average Time”與“90 Percent Time”都可以，如果整體趨勢毫無規律，波動非常大，我們就不用“Average Time”而使用“90 Percent Time”可能更真實些。

    從圖5- 10可以看出，所有Action平均事務響應時間的趨勢都非常平滑，所以使用“Average Time”與“90 Percent Time”差別不是很大，用哪個都可以。這裡是使用最常用的統計方法“90 Percent Time”。登入業務的“90 Percent Time”是5.298秒-3秒（思考時間）=2.298秒，考勤業務的“90 Percent Time”是1.469秒，沒有思考時間，那麼就是實打實的啦。根據上面的計算，本次測試結果記錄如表1所示。

測試項	目標值	實際值	是否通過
登入業務響應時間	<=3秒	2.298秒	Y
考勤業務響應時間	<=3秒	1.469秒	Y
登入業務成功率	100%
考勤業務成功率	100%
登入業務總數	30分鐘完成2000
考勤業務總數	30分鐘完成2000
CPU使用率	<75%
記憶體使用率	<70%

                           表1測試結果對照表一

• 每秒點選數

　　“Hits per Second（每秒點選數）”反映了客戶端每秒鐘向伺服器端提交的請求數量，如果客戶端發出的請求數量越多，與之相對的“Average Throughput (bytes/second)”也應該越大，並且發出的請求越多會對平均事務響應時間造成影響，所以在測試過程中往往將這三者結合起來分析。圖1- 11顯示的是“Hits per Second”與“Average Throughput(bytes/second)”的複合圖，從圖中可以看出，兩種圖形的曲線都正常並且基本一致，說明伺服器能及時的接受客戶端的請求，並能夠返回結果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，則表示伺服器雖然能夠接受伺服器的請求，但返回結果較慢，可能是程式處理緩慢。如果“Hits per Second”不正常，則說明客戶端存在問題，那種問題一般是網路引起的，或者錄製的指令碼有問題，未能正確的模擬使用者的行為。具體問題具體分析，這裡僅給出一些建議。

          

                      圖1- 11每秒點選數與每秒吞吐量複合圖

    對於本次測試來說，“Hits per Second”與“Average Throughput (bytes/second)”都是正常的，而且整體表現還是不錯的。

    一般情況下，這兩種指標用於效能調優，比如給定了幾個條件，去檢測另外一個條件，用這兩個指標衡量，往往起到很好的效果。比如要比較某兩種硬體平臺的優劣，就可以使用相同的配置方法部署軟體系統，然後使用相同的指令碼、場景設計、統計方法去分析，最終得出一個較優的配置。

• 業務成功率

　 “業務成功率”這個指標在很多系統中都提及到，比如電信的、金融的、企業資源管理的等等。舉個例子，我們樓下的建行，假如每天的業務類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等，那麼在做他們的營業系統測試時就需要考慮業務成功率了，一般不得低於98%。具體的業務成功率是什麼意思呢？排除那些複雜的業務，比如非同步處理的業務（移動的套卡開通就是非同步的），業務成功率就是事務成功率，使用者一般把一個Aciton當做一筆業務，在LoadRunner場景執行中一筆交易稱為一個事務。所以，說業務成功率其實就是事務成功率、通過率的意思。在“Transaction Summary”中我們可以很明確的看到每個事務的執行狀態，如圖1- 12所示。

            

                          圖1- 12事務狀態統計圖

    從圖中可以看出，所有的Aciton都是綠色的，即表示為Passed，同時除了vuser_init與vuser_end兩個事務，其他的事務通過數為2163，也就表明在30分鐘的時間裡，共完成了2163次登入考勤業務操作。那麼根據這些可以判斷本次測試登入業務與考勤業務的成功率是100%，再次更新測試結果記錄表如表2所示。

測試項	目標值	實際值	是否通過
登入業務響應時間	<=3秒	2.298秒	Y
考勤業務響應時間	<=3秒	1.469秒	Y
登入業務成功率	100%	100%	Y
考勤業務成功率	100%	100%	Y
登入業務總數	30分鐘完成2000	2163	Y
考勤業務總數	30分鐘完成2000	2163	Y
CPU使用率	<75%
記憶體使用率	<70%

                            表2測試結果對照表二

• 系統資源

　　系統資源圖顯示了在場景執行過程中被監控的機器系統資源使用情況，一般情況下監控機器的CPU、記憶體、網路、磁碟等各個方面。本次測試監控的是測試伺服器的CPU使用率與記憶體使用率，以及處理器佇列長度，具體的資料如圖1- 13所示。

            

                         圖1- 13測試伺服器系統資源監控結果圖

    從圖中可以看出，CPU使用率、可用實體記憶體、CPU的佇列長度三個指標的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、8.45，而測試伺服器總的實體記憶體為384M，那麼記憶體使用率為（384-83.456）/384=78.26%，根據本次效能測試要求的：CPU使用率不超過75%，實體記憶體使用率不超過70%這兩點來看，記憶體的使用率78.26%大於預期的70%，故記憶體使用率不達標。根據Windwos資源效能指標的解釋，一般情況下，如果“Processor Queue Length（處理器佇列長度）”一直超過二，則可能表示處理器堵塞，我們這裡監控出來的數值是8.45，而且總體上保持平衡，那麼由此推斷，測試伺服器的CPU也可能是個瓶頸。同時在測試過程中，場景執行到23分半鐘的時候，報出了錯誤！未找到引用源。的錯誤，意思是說被監控的伺服器當前無法再進行計數器資料的獲取了，所以，本次作業系統資源的監控只得到了場景執行的前23分半鐘的資料。這樣對本次測試結果有一定的影響。

     獲得上述資料後，最新的測試結果記錄表如表3所示。

                               表3測試結果對照表三

     從上表資料來看，本次測試總體上已經達到了預期的效能指標，但從其他的資料，比如CPU的佇列長度、記憶體使用率來看，被測伺服器的硬體資源需要提升。

• 網頁細分圖

　　網頁細分圖可以評估頁面內容是否影響事務響應時間。使用網頁細分圖，可以分析網站上有問題的元素（例如下載很慢的影象或打不開的連結）。

    我們這裡檢視一下網頁細分圖中的“Page Download Time Breakdown”，點選錯誤！未找到引用源。左邊的“New Graph”，出現圖1- 14，展開“Web Page Diagnostics”前的加號，雙擊“Page Download Time Breakdown”，待出現“Page Download Time Breakdown”監控圖後，點選【Close】按鈕關閉新增監控圖介面。

                        

                      圖1- 14新增網頁細分圖

    在監控圖列表中，我們看到圖1- 15，從圖中我們看到，在所有的頁面中，登入後的用個人面頁面“http://192.168.0.52:8080/oa/oa.jsp”的下載時間最長。

                              

                             圖1- 15網頁下載時間細分圖

    圖1- 16詳細列出了每個頁面所消耗的時間分佈，圖中每一個指標含義見表4所示。該表由LoadRunner使用手冊提供。通過這些指標的資料，我們可以輕易的判斷是哪個頁面、哪個請求導致了響應時間變長，甚至響應失敗。

                   

                         圖1- 16 oa.jsp頁面下載時間分佈圖

                          表4網頁下載時間細分指標說明

    對於本次測試，從網頁細分圖來看，基本上每個頁面的載入時間都是預期範圍內，oa.jsp頁面因為整合了使用者的個人工作平臺，需要檢索很多的資料，併合成了很多圖片，所以相應的載入時間較長，這是正確的。

• Web伺服器資源

　　上述所有的監控圖形LoadRunner都可以提供，但對於某些測試監控圖來說，LoadRunner就沒有提供了，期望其新版支援這些功能，當然想監控Tomcat、Jboss或者其他的Web伺服器可以SiteScope工具，這個工具配置較為複雜，根據個人需要吧。我這裡監控Tomcat使用的是ManageEngine Applications Manager 8的試用版，測試結束後得出Tomcat的JVM使用率如圖1- 17所示。

                                                                 

                    圖1- 17 Tomcat JVM使用率監檢視

    從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時共分配了100M左右的實體記憶體給其，測試初期使用的JVM相對來說較少，我們的測試場景是從15:58:40開始，到16:29:42結束，共歷時31分2秒。從圖中看到，從16:00到16:30這個時間內，也就是測試場景執行期間，JVM的使用率不斷上升，並沒有在請求達到均衡狀態後也呈現一種平衡狀態，所以，從這點可以推斷，如果測試場景繼續執行，或者加大併發數，最終必將導致Tomcat記憶體不夠用而報出“Out Of Memory”記憶體溢位的錯誤。在正常情況下，記憶體的使用應該與“Hit per Second”、“Average Throughput (bytes/second)”等監控圖的圖形走勢是一致的。

     從上述過程可以得出一個結論，出現圖1- 17中的問題，可能有兩個原因：

     1、Tomcat的記憶體分配不足；

     2、程式程式碼有錯誤，可能導致記憶體洩露。

    解決方法：

    1、為Tomcat分配更多的記憶體，如果是使用的catalina.sh或Catalina.bat啟動的Tomcat，則可在這兩個檔案中新增“SET CATALINA_OPTS= -Xms300m–Xmx300m”，如果使用的winnt服務方式啟動的Tomcat，則可在“執行”中輸入“regedit”進入登錄檔，然後在“HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters”修改兩個屬性，一個是JvmMs，另外一個是JvmMx，如圖1- 18所示。

    2、檢查程式程式碼，使用一些記憶體洩露檢查工具進行清查。

                        

                   圖1- 18修改Tocat的JVM資料

• 資料庫伺服器資源

     資料庫伺服器資源監控相對來說就複雜的多了，現在常用的資料有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供對後面幾種資料庫的監控方法，但對Mysql沒有提供對應的監控方法。他不提供，我們們就自己找監控工具，我這裡使用的是Spotlight，該工具監控資料庫的好處是配置連線簡單，不僅能監控資料庫，還能監控作業系統的資源，監控結果直觀明瞭。錯誤！未找到引用源。顯示了Mysql資料庫在場景執行過程中SQL語句的執行情況，從圖中可以看到，“Selects（查詢）”與“Inserts（插入）”兩種語句執行的趨勢在場景執行過程中是比較平滑，並且測試中沒有錯誤發現，也就說明在處理相關業務時Mysql的處理是正常的。假如這兩種SQL語句任何一個出現波動很大的情況，就可以推出在場景執行過程中存在頁面錯誤，因為這些語句不執行，就表明某些頁面未被載入或者某些功能未被使用。在本次測試中，OA系統的“oa.jsp”頁面有大量的“Selects（查詢）”語句，而考勤操作則是“Inserts（插入）”，所以，只要有一方出問題，必然表示測試過程中存在頁面打不開或者考勤不成功的錯誤。