• 測試結果分析

　　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的平均響應時間與業務成功率。

註意：

　　因為在場景的“Run-time Settings”的“Miscellaneous”選項中將每一個Action當成了一個事務執行，故這裏的事務其實就是腳本中的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狀態代碼如下：

400 無法解析此請求。

401.1 未經授權：訪問由於憑據無效被拒絕。

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.1錯誤只會出現在具有多個IP地址的計算機上。如果在特定IP地址/端口組合上收到客戶端請求，而且沒有將IP地址配置為在該特定的端口上偵聽，則IIS返回 404.1 HTTP錯誤。例如，如果一臺計算機有兩個IP地址，而只將其中一個IP地址配置為在端口80上偵聽，則另一個IP地址從端口80收到的任何請求都將導致IIS返回404.1錯誤。只應在此服務級別設置該錯誤，因為只有當服務器上使用多個IP地址時才會將它返回給客戶端。

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所示。

表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所示。

表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，該工具監控數據庫的好處是配置連接簡單，不僅能監控數據庫，還能監控操作系統的資源，監控結果直觀明了。

(此處應該有張Spotlight的界面圖，但是被百度吞了，查詢未果)

顯示了Mysql數據庫在場景執行過程中SQL語句的執行情況，從圖中可以看到，“Selects（查詢）”與“Inserts（插入）”兩種語句執行的趨勢在場景執行過程中是比較平滑，並且測試中沒有錯誤發現，也就說明在處理相關業務時Mysql的處理是正常的。假如這兩種SQL語句任何一個出現波動很大的情況，就可以推出在場景執行過程中存在頁面錯誤，因為這些語句不執行，就表明某些頁面未被加載或者某些功能未被使用。在本次測試中，OA系統的“oa.jsp”頁面有大量的“Selects（查詢）”語句，而考勤操作則是“Inserts（插入）”，所以，只要有一方出問題，必然表示測試過程中存在頁面打不開或者考勤不成功的錯誤。

--------------------------------------------

原文作者：猥瑣丶欲為

傳送門：http://www.cnblogs.com/hyzhou/archive/2011/11/16/2251316.html

(轉)LR性能測試結果樣例分析