web項目測試實戰(zhàn)性能測試結(jié)果分析樣章

1、LoadRunner性能測試結(jié)果分析是個復雜的過程，通常可以從結(jié)果摘要、并發(fā)數(shù)、平均事務響應時間、每秒 點擊數(shù)、業(yè)務成功率、系統(tǒng)資源、網(wǎng)頁細分圖、Web服務器資源、數(shù)據(jù)庫服務器資源等幾個方面分析，如錯誤!未指定書簽。所示。性能測試結(jié)果分析的一個重要的原則是以性能測試的需求指標為導向。我們回顧一下本次性能測試的目的，正如 錯誤！未指定書簽。所列的指標，本次測試的要求是驗證在30分鐘內(nèi)完成2000次用戶登錄系統(tǒng)，然后進行考勤業(yè)務，最后退出，在業(yè)務操作過程中頁面的響應時間不超過3秒，并且服務器的 CPU使用率、內(nèi)存使用率分別不超過75%、70%,那么按照所示的流程，我們開始分析，看看本次測試是否達到

2、了預期的性能指標，其中又有哪些性能隱患，該如何解決。圖5- 1性能測試結(jié)果分析流程圖結(jié)果摘要LoadRunner進行場景測試結(jié)果收集后，首先顯示的該結(jié)果的一個摘要信息，如 錯誤!未指定書簽。所示。概 要中列出了場景執(zhí)行情況、" Statistics Summary （統(tǒng)計信息摘要）"、"Transaction Summary （事務摘要）”以 及"HTTP Responses Summary （HTTP響應摘要）”等。以簡要的信息列出本次測試結(jié)果。圖5- 2性能測試結(jié)果摘要圖場景執(zhí)行情況該部分給出了本次測試場景的名稱、結(jié)果存放路徑及場景的持續(xù)時間，如錯誤

3、！未指定書簽。所示。從該圖我們知道，本次測試從 15:58:40開始，到16:29:42結(jié)束，共歷時31分2秒。與我們場景執(zhí)行計劃中設計的時間 基本吻合。圖5- 3場景執(zhí)行情況描述圖Statistics Summary （統(tǒng)計信息摘要）該部分給出了場景執(zhí)行結(jié)束后并發(fā)數(shù)、總吞吐量、平均每秒吞吐量、總請求數(shù)、平均每秒請求數(shù)的統(tǒng)計值， 如錯誤！未指定書簽。所示。從該圖我們得知，本次測試運行的最大并發(fā)數(shù)為7,總吞吐量為842,037,409字節(jié)，平均每秒的吞吐量為 451,979字節(jié)，總的請求數(shù)為 211,974,平均每秒的請求為 113.781 ,對于吞吐量，單位時間 內(nèi)吞吐量越大，說明服務器的處理

4、能越好，而請求數(shù)僅表示客戶端向服務器發(fā)出的請求數(shù)，與吞吐量一般是成正比關(guān)系。圖5- 4統(tǒng)計信息摘要圖Transaction Summary（事務摘要）該部分給出了場景執(zhí)行結(jié)束后相關(guān)Action的平均響應時間、通過率等情況，如 錯誤!未指定書簽。所示。從該圖我們得到每個 Action的平均響應時間與業(yè)務成功率。注意：因為在場景的“Run-time Settings"的"Miscellaneous"選項中將每一個 Action當成了一 個事務執(zhí)行，故這里的事務其實就是腳本中的Action o圖5- 5事務摘要圖HTTP Responses Summary （HTTP

5、響應摘要）該部分顯示在場景執(zhí)彳T過程中，每次 HTTP請求發(fā)出去的狀態(tài)，是成功還是失敗，都在這里體現(xiàn)，如錯誤!未指定書簽。所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發(fā)出了 211974次請求（與“統(tǒng)計信息摘要”中的“ Total Hits ” 一致），其中“ HTTP 200 ”的是209811次，而“ HTTP 404 ”貝U有2163,說明在本 次過程中，經(jīng)過發(fā)出的請求大部分都能正確響應了，但還是有部分失敗了，但未影響測試結(jié)果，“HTTP 200”表示請求被正確響應，而“ HTTP 404 ”表示文件或者目錄未能找到。有朋友可能會問，這里出現(xiàn)了404的錯誤，為什么結(jié)果

6、還都通過了。出現(xiàn)這樣問題的原因是腳本有些頁面的請求內(nèi)容并非關(guān)鍵點，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結(jié)果。圖5- 6 HTTP響應摘要常用的HTTP狀態(tài)代碼如下:400無法解析此請求。401.1 未經(jīng)授權(quán)：訪問由于憑據(jù)無效被拒絕。401.2 未經(jīng)授權(quán)：訪問由于服務器配置傾向使用替代身份驗證方法而被拒絕。401.3 未經(jīng)授權(quán)：訪問由于 ACL對所請求資源的設置被拒絕。401.4 未經(jīng)授權(quán)：Web服務器上安裝的篩選器授權(quán)失敗。401.5 未經(jīng)授權(quán)：ISAPI/CGI應用程序授權(quán)失敗。401.7 未經(jīng)授權(quán)：由于 Web服務器上的 URL授權(quán)策略而拒絕訪問。

7、403禁止訪問：訪問被拒絕。403.1 禁止訪問403.2 禁止訪問403.3 禁止訪問403.4 禁止訪問403.5 禁止訪問403.6 禁止訪問403.7 禁止訪問執(zhí)行訪問被拒絕。讀取訪問被拒絕。寫入訪問被拒絕。需要使用SSL查看該資源。需要使用SSL 128查看該資源?？蛻舳说腎P地址被拒絕。需要 SSL客戶端證書。403.8禁止訪問403.9禁止訪問客戶端的DNS名稱被拒絕。太多客戶端試圖連接到Web服務器。403.10 禁止訪問403.11 禁止訪問403.12 禁止訪問403.13 禁止訪問403.14 禁止訪問403.15 禁止訪問403.16 禁止訪問403.17 禁止訪問40

8、3.18 禁止訪問403.19 禁止訪問403.20 禁止訪問Web服務器配置為拒絕執(zhí)行訪問。密碼已更改。服務器證書映射器拒絕了客戶端證書訪問?？蛻舳俗C書已在Web服務器上吊銷。在 Web服務器上已拒絕目錄列表。Web服務器已超過客戶端訪問許可證限制?？蛻舳俗C書格式錯誤或未被Web服務器信任?？蛻舳俗C書已經(jīng)到期或者尚未生效。無法在當前應用程序池中執(zhí)行請求的URL。無法在該應用程序池中為客戶端執(zhí)行CGI。Passport登錄失敗。404找不到文件或目錄。404.1文件或目錄未找到：網(wǎng)站無法在所請求的端口訪問。需要注意的是404.1錯誤只會出現(xiàn)在具有多個IP地址的計算機上。如果在特定IP地址/端口

9、組合上收到客戶端請求，而且沒有將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服務器需要初始的代理

10、驗證。410文件已刪除。412客戶端設置的前提條件在Web服務器上評估時失敗。414請求URL太大，因此在 Web服務器上不接受該 URL。500服務器內(nèi)部錯誤。500.11 服務器錯誤：Web服務器上的應用程序正在關(guān)閉。500.12 服務器錯誤：Web服務器上的應用程序正在重新啟動。500.13 服務器錯誤：Web服務器太忙。500.14 服務器錯誤：服務器上的無效應用程序配置。500.15 服務器錯誤：不允許直接請求GLOBAL.ASA 。500.16 服務器錯誤：UNC授權(quán)憑據(jù)不正確。500.17 服務器錯誤：URL授權(quán)存儲無法找到。500.18 服務器錯誤：URL授權(quán)存儲無法打開。50

11、0.19 服務器錯誤：該文件的數(shù)據(jù)在配置數(shù)據(jù)庫中配置不正確。500.20 服務器錯誤：URL授權(quán)域無法找到。500 100內(nèi)部服務器錯誤：ASP錯誤。501標題值指定的配置沒有執(zhí)行。502 Web服務器作為網(wǎng)關(guān)或代理服務器時收到無效的響應。并發(fā)數(shù)分析“Running Vusers (運行的并發(fā)數(shù))”顯示了在場景執(zhí)行過程中并發(fā)數(shù)的執(zhí)行情況。它們顯示Vuser的狀態(tài)、完成腳本的Vuser的數(shù)量以及集合統(tǒng)計信息，將這些圖與事務圖結(jié)合使用可以確定Vuser的數(shù)量對事務響應時間產(chǎn)生的影響。錯誤！未指定書簽。顯示了在OA系統(tǒng)考勤業(yè)務性能測試過程中Vusers運行情況，從圖中我們可以看到，Vusers的運行

12、趨勢與我們場景執(zhí)行計劃中的設置是一樣，表明在場景執(zhí)行過程中，Vusers是按照我們預期的設置運行的，沒有Vuser出現(xiàn)運行錯誤，這樣從另一個側(cè)面說明我們的參數(shù)化設置是正確的，因為使用唯一數(shù)進行參數(shù)化設置，如果設置不正確，將會導致Vuser運行錯誤。在腳本中我們加入了這樣一段代碼：if (atoi(lr_eval_string("num") > 0)lr_output_message("登錄成功，繼續(xù)執(zhí)行 .")； else lr_error_message("登錄失敗，退出測試 ")； return -1;上述代碼的意思是說，如

13、果登錄失敗了，就退出腳本的迭代，那么什么原因可能會導致登錄失敗呢？就是我們前面參數(shù)化的設置，一旦 Vuser分配不到正確的登錄賬號，就可能導致登錄失敗，從而引起 Vuser停止運行。 所以，從 錯誤!未指定書簽。的表現(xiàn)，可以認為參數(shù)化是沒有問題的。圖5- 7運行的并發(fā)數(shù)圖測試腳本中我們還使用了集合點，那么這里還可以看看集合點在場景執(zhí)行過程中的表現(xiàn)，點擊左邊的“NewGraph”,出現(xiàn)錯誤!未指定書簽。，展開"Vusers”前的加號，雙擊“Rendezvous”,出現(xiàn)集合點的圖形后，點 擊【Close，關(guān)閉添加新圖界面。圖5- 8添加集合點統(tǒng)計圖集合點的圖形如 錯誤！未指定書簽。所示，

14、從圖中可以看到，所有用戶到達集合點后，立刻就釋放了。與之前設定的集合點策略設置“所有運行用戶到達后釋放“是一致的。假設這樣的一種情況，Running的Vusers有10個，集合點策略設置是“所有運行用戶到達后釋放”，而集合點圖形顯示的最大釋放Vusers是7個，那么就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應超時了，可以結(jié)合平均事務響應時間再詳細分析原因。圖5- 9集合點狀態(tài)圖OA系我們本次測試 Running Vusers與集合點是一致，說明整個場景執(zhí)行過程中，并發(fā)數(shù)用戶的執(zhí)行正確, 統(tǒng)測試服務器能夠應付7個并發(fā)用戶的業(yè)務操作。響應時間在性能測試要求中我們知道，有一項

15、指標是要求登錄、考勤業(yè)務操作的頁面響應時間不超過 3秒，那么本次 測試是否達到了這個要求呢？我們先來看" Average Transaction Response Time （平均事務響應時間圖）" （錯誤! 未指定書簽。），這張圖是平均事務響應時間與結(jié)果摘要中的"Transaction Summary”合成的。圖5- 10平均事務響應時間圖從圖形下部我們可以看到，登錄部分對應的Action是“submit_login : 考勤業(yè)務提交對應的Action是"submit_sign",他們的"Average Time （平均響應時間為）

16、”分別是 4.425秒與0.848秒，從這兩個數(shù)值來看， 考勤業(yè)務的事務響應時間0.848秒小于預期的3秒，達到了要求，而登錄是4.425秒，大于預期的3秒，不符合要求。這樣的結(jié)果是不正確的，因為在統(tǒng)計的登錄業(yè)務的時候，我們沒有去除思考時間，所以，登錄功能的實際 事務時間應該是 4.425秒-3秒=1.425秒，小于預期的3秒，故登錄業(yè)務的事務響應時間也達到了我們的要求。在 平時的性能測試活動中，統(tǒng)計結(jié)果的時候需要去掉思考時間，加上思考時間是為了真實的模擬用戶環(huán)境，統(tǒng)計結(jié)果中除去思考時間是為了更真實的反映服務器的處理能力，兩者并不矛盾?？赐炅?" Average Time ”,我們再

17、看"90 Percent Time”,這個時間從某種程度來說，更準確衡量了測試過 程中各個事務的真實情況，表示90%的事務，服務器的響應都維持在某個值附近，“ Average Time ”值對于平均事務響應時間變動趨勢很大的情況統(tǒng)計就不準確了，比如有三個時間：1秒、5秒、12秒，則平均時間為 6秒，而另外一種情況：5秒、6秒、7秒，平均時間也為 6秒，顯然第二種比第一種要穩(wěn)定多了。所以，我們在查看 平均事務響應時間的時候， 先看整體曲線走勢， 如果整體趨勢比較平滑， 沒有忽上忽下的波動情況， 取“Average Time"與"90 Percent Time”都可以

18、，如果整體趨勢毫無規(guī)律，波動非常大，我們就不用" Average Time”而使 用“90 Percent Time”可能更真實些。從錯誤!未指定書簽。可以看出，所有Action平均事務響應時間的趨勢都非常平滑，所以使用“Average Time”與“90 Percent Time”差別不是很大，用哪個都可以。這里是使用最常用的統(tǒng)計方法“90 Percent Time ”。登錄業(yè)務的“ 90 Percent Time”是5.298秒-3秒（思考時間）=2.298秒，考勤業(yè)務的“ 90 Percent Time”是1.469秒， 沒有思考時間，那么就是實打?qū)嵉睦?。根?jù)上面的計算，本次測

19、試結(jié)果記錄如錯誤！未指定書簽。所示。測試項目標值實際值是否通過登錄業(yè)務響應時間<=3秒2.298 秒Y考勤業(yè)務響應時間<=3秒1.469 秒Y登錄業(yè)務成功率100%考勤業(yè)務成功率100%登錄業(yè)務總數(shù)30分鐘完成2000考勤業(yè)務總數(shù)30分鐘完成2000CPU使用率<75%內(nèi)存使用率<70%表5- 1測試結(jié)果對照表一每秒點擊數(shù)“Hits per Second (每秒點擊數(shù))”反映了客戶端每秒鐘向服務器端提交的請求數(shù)量，如果客戶端發(fā)出的請 求數(shù)量越多，與之相對的" Average Throughput (bytes/second)"也應該越大，并且發(fā)出的請

20、求越多會對平均事務 響應時間造成影響，所以在測試過程中往往將這三者結(jié)合起來分析。錯誤!未指定書簽。顯示的是“Hits per Second”與"Average Throughput (bytes/second)”的復合圖，從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說 明服務器能及時的接受客戶端的請求，并能夠返回結(jié)果。如果" Hits per Second"正常，而"Average Throughput (bytes/second)”不正常，則表示服務器雖然能夠接受服務器的請求，但返回結(jié)果較慢，可能是程序處理緩慢。如 果“Hits per Seco

21、nd”不正常，則說明客戶端存在問題，那種問題一般是網(wǎng)絡引起的，或者錄制的腳本有問題， 未能正確的模擬用戶的行為。具體問題具體分析，這里僅給出一些建議。圖5- 11每秒點擊數(shù)與每秒吞吐量復合圖對于本次測試來說，"Hits per Second"與"Average Throughput (bytes/second)"都是正常的，而且整體表現(xiàn) 還是不錯的。一般情況下，這兩種指標用于性能調(diào)優(yōu)，比如給定了幾個條件，去檢測另外一個條件，用這兩個指標衡量，往往起到很好的效果。比如要比較某兩種硬件平臺的優(yōu)劣，就可以使用相同的配置方法部署軟件系統(tǒng)，然后使用相同的腳本、場景

22、設計、統(tǒng)計方法去分析，最終得出一個較優(yōu)的配置。業(yè)務成功率“業(yè)務成功率”這個指標在很多系統(tǒng)中都提及到，比如電信的、金融的、企業(yè)資源管理的等等。舉個例子，我們樓下的建行，假如每天的業(yè)務類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等,那么在做他們的營業(yè)系統(tǒng)測試時就需要考慮業(yè)務成功率了，一般不得低于98%。具體的業(yè)務成功率是什么意思呢？排除那些復雜的業(yè)務，比如異步處理的業(yè)務(移動的套卡開通就是異步的)，業(yè)務成功率就是事務成功率，用戶一般把一個 Aciton當做一筆業(yè)務，在 LoadRunner場景執(zhí)行中一筆交易稱為一個事務。所以，說業(yè)務成功率 其實就是事務成功率、通過率的

23、意思。在"Transaction Summary”中我們可以很明確的看到每個事務的執(zhí)行狀態(tài)， 如錯誤！未指定書簽。 所示。圖5- 12事務狀態(tài)統(tǒng)計圖從圖中可以看出，所有的 Aciton都是綠色的，即表示為 Passed,同時除了 vuser_init與vuser_end兩個事務, 其他的事務通過數(shù)為 2163,也就表明在30分鐘的時間里，共完成了2163次登錄考勤業(yè)務操作。那么根據(jù)這些可以判斷本次測試登錄業(yè)務與考勤業(yè)務的成功率是100%,再次更新測試結(jié)果記錄表如錯誤！未指定書簽。 所示。測試項目標值實際值是否通過登錄業(yè)務響應時間<=3秒2.298 秒Y考勤業(yè)務響應時間<=

24、3秒1.469 秒Y登錄業(yè)務成功率100%100%Y考勤業(yè)務成功率100%100%Y登錄業(yè)務總數(shù)30分鐘完成20002163Y考勤業(yè)務總數(shù)30分鐘完成20002163YCPU使用率<75%內(nèi)存使用率<70%表5- 2測試結(jié)果對照表二系統(tǒng)資源系統(tǒng)資源圖顯示了在場景執(zhí)行過程中被監(jiān)控的機器系統(tǒng)資源使用情況，一般情況下監(jiān)控機器的CPU、內(nèi)存、網(wǎng)絡、磁盤等各個方面。本次測試監(jiān)控的是測試服務器的CPU使用率與內(nèi)存使用率，以及處理器隊列長度，具體的數(shù)據(jù)如 錯誤！未指定書簽。所示。圖5- 13測試服務器系統(tǒng)資源監(jiān)控結(jié)果圖從圖中可以看出，CPU使用率、可用物理內(nèi)存、CPU的隊列長度三個指標的曲線逗較

25、為平滑，三者的平均值分別為：53.582%、83.456M、8.45,而測試服務器總的物理內(nèi)存為384M ,那么內(nèi)存使用率為（384-83.456）/384=78.26% ,根據(jù)本次性能測試要求的：CPU使用率不超過75%,物理內(nèi)存使用率不超過 70%這兩點來看，內(nèi)存的使用率78.26%大于預期的70%,故內(nèi)存使用率不達標。根據(jù) Windwos資源性能指標的解釋，一般情況下， 如果“Processor Queue Length （處理器隊列長度）”一直超過二，則可能表示處理器堵塞，我們這里監(jiān)控出來 的數(shù)值是8.45,而且總體上保持平衡，那么由此推斷，測試服務器的CPUm可能是個瓶頸。同時在測試

26、過程中，場景執(zhí)行到23分半鐘的時候，報出了錯誤！未指定書簽。的錯誤，意思是說被監(jiān)控的服務器當前無法再進行計數(shù) 器數(shù)據(jù)的獲取了，所以，本次操作系統(tǒng)資源的監(jiān)控只得到了場景執(zhí)行的前23分半鐘的數(shù)據(jù)。這樣對本次測試結(jié)果有一定的影響。獲得上述數(shù)據(jù)后，最新的測試結(jié)果記錄表如錯誤！未指定書簽。所示。測試項目標值實際值是否通過登錄業(yè)務響應時間<=3秒2.298 秒Y考勤業(yè)務響應時間<=3秒1.469 秒Y登錄業(yè)務成功率100%100%Y考勤業(yè)務成功率100%100%Y登錄業(yè)務總數(shù)30分鐘完成20002163Y考勤業(yè)務總數(shù)30分鐘完成20002163YCPU使用率<75%53.582%Y內(nèi)存使

27、用率<70%78.26%N表5- 3測試結(jié)果對照表三從上表數(shù)據(jù)來看，本次測試總體上已經(jīng)達到了預期的性能指標，但從其他的數(shù)據(jù)，比如CPU的隊列長度、內(nèi)存使用率來看，被測服務器的硬件資源需要提升。網(wǎng)頁細分圖網(wǎng)頁細分圖可以評估頁面內(nèi)容是否影響事務響應時間。使用網(wǎng)頁細分圖，可以分析網(wǎng)站上有問題的元素（例如下載很慢的圖像或打不開的鏈接）。我們這里查看一下網(wǎng)頁細分圖中的"Page Download Time Breakdown "，點擊錯誤！未指定書簽。左邊的"NewGraph”,出現(xiàn)錯誤!未指定書簽。，展開"Web Page Diagnostics"

28、;前的加號，雙擊"Page Download Time Breakdown ", 待出現(xiàn)"Page Download Time Breakdown ”監(jiān)控圖后，點擊【Close按鈕關(guān)閉添加監(jiān)控圖界面。圖5- 14添加網(wǎng)頁細分圖在監(jiān)控圖列表中，我們看到錯誤！未指定書簽。，從圖中我們看到，在所有的頁面中，登錄后的用個人面頁面“”的下載時間最長。圖5- 15網(wǎng)頁下載時間細分圖錯誤！未指定書簽。詳細列出了每個頁面所消耗的時間分布，圖中每一個指標含義見 錯誤!未指定書簽。所示。該表由LoadRunner使用手冊提供。通過這些指標的數(shù)據(jù)，我們可以輕易的判斷是哪個頁面、哪個請求

29、導致了響 應時間變長，甚至響應失敗。圖5- 16 oa.jsp頁面下載時間分布圖名稱描述Client Time顯示因瀏覽器思考時間或其他與客戶端有關(guān)的延遲而使客戶機上的請求發(fā) 生延遲時，所經(jīng)過的平均時間。Connection Time顯示與包含指定 URL的Web服務器建立初始連接所需的時間。連接度量是一個很好的網(wǎng)絡問題才前滯1。此外，它還可表明服務器是否對請求做出響應。DNS ResolutionTime顯示使用最近的 DNS!艮務器將DNS稱解析為IP地址所需的時間。DNSS 找度量是指示DNS解析問題或DNS服務器問題的一個很好的指示器。Error Time顯示從發(fā)出HTTP請求到返回錯

30、誤消息（僅限于HTTP錯誤）這期間經(jīng)過的平均時間。First Buffer Time顯示從初始HTTP請求（通常為GET到成功收回來自 Web服務器的第一次 緩沖時為止所經(jīng)過的時間。 A 次緩沖度量是很好的 Web服務器延遲和網(wǎng) 絡滯后指示器。（注意：由于緩沖區(qū)大小最大為8K,因此A次緩沖時間可能也就是完成元素下載所需的時間。）FTPAuthernticationTime顯示驗證客戶端所用的時間。如果使用FTP,則服務器在開始處理客戶端命令之前，必須驗證該客戶端。FTP驗證度量僅適用于 FTP協(xié)議通信Receive Time顯示從服務器收到最舟-個字節(jié)并完成下載之前經(jīng)過的時間。接收度量是很好的

31、網(wǎng)絡質(zhì)量指示器（查看用來計算接收速率的時間/大小比率）。SSL HandshakingTime顯示建立SSL連接（包括客戶端hello、服務器hello、客戶端公用密鑰傳 輸、服務器證書傳輸和其他部分可選階段）所用的時間。此時刻后，客戶端和服務器之間的所有通信都被加密。SSL握手度量僅適用于 HTTPS通信。表5- 4網(wǎng)頁下載時間細分指標說明對于本次測試，從網(wǎng)頁細分圖來看，基本上每個頁面的加載時間都是預期范圍內(nèi)，oa.jsp頁面因為集成了用戶的個人工作平臺，需要檢索很多的數(shù)據(jù)，并合成了很多圖片，所以相應的加載時間較長，這是正確的。Web服務器資源上述所有的監(jiān)控圖形 LoadRunner都可以提

32、供，但對于某些測試監(jiān)控圖來說，LoadRunner就沒有提供了，期望其新版支持這些功能，當然想監(jiān)控Tomcat、Jboss或者其他的 Web服務器可以SiteScope工具，這個工具配置 較為復雜，根據(jù)個人需要吧。 我這里監(jiān)控Tomcat使用的是 ManageEngine Applications Manager 8的試用版，測試 結(jié)束后得出Tomcat的JVM使用率如錯誤!未指定書簽。 所示。圖5- 17 Tomcat JVM使用率監(jiān)視圖從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置 Tomcat時共分配了 100M左右的物理內(nèi)存給其，測試初期使用的 JVM相對來說較少，我們的測試場景是從 15:58:40開始，到16:29:42結(jié)束，共歷時31 分2秒。從圖中看到，從16:00到16:30這個時間內(nèi)，也就是測試場景執(zhí)行期間，JVM的使用率不斷上升，并沒有在請求達到均衡狀態(tài)后也呈現(xiàn)一種平衡狀態(tài)，所以，從這點可以推斷，如果測試場景繼續(xù)執(zhí)行，或者加大并發(fā) 數(shù)，最終必將導致 Tomcat內(nèi)存不夠用而報出“Out Of Memory ”內(nèi)存溢出的錯誤。在正常情況下，內(nèi)存的使用應 該與"Hit per Second"、"Average Thr