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

LR性能測試結(jié)果樣例分析LR性能測試結(jié)果樣例分析/NUMPAGES36LR性能測試結(jié)果樣例分析LR性能測試結(jié)果樣例分析

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

測試結(jié)果分析LoadRunner性能測試結(jié)果分析是個(gè)復(fù)雜的過程，通?？梢詮慕Y(jié)果摘要、并發(fā)數(shù)、平均事務(wù)響應(yīng)時(shí)間、每秒點(diǎn)擊數(shù)、業(yè)務(wù)成功率、系統(tǒng)資源、網(wǎng)頁細(xì)分圖、Web服務(wù)器資源、數(shù)據(jù)庫服務(wù)器資源等幾個(gè)方面分析，如圖1-1所示。性能測試結(jié)果分析的一個(gè)重要的原則是以性能測試的需求指標(biāo)為導(dǎo)向。我們回顧一下本次性能測試的目的，正如所列的指標(biāo)，本次測試的要求是驗(yàn)證在30分鐘內(nèi)完成2000次用戶登錄系統(tǒng)，然后進(jìn)行考勤業(yè)務(wù)，最后退出，在業(yè)務(wù)操作過程中頁面的響應(yīng)時(shí)間不超過3秒，并且服務(wù)器的CPU使用率、內(nèi)存使用率分別不超過75%、70%，那么按照所示的流程，我們開始分析，看看本次測試是否達(dá)到了預(yù)期的性能指標(biāo)，其中又有哪些性能隱患，該如何解決。圖1-1性能測試結(jié)果分析流程圖結(jié)果摘要LoadRunner進(jìn)行場景測試結(jié)果收集后，首先顯示的該結(jié)果的一個(gè)摘要信息，如圖1-2所示。概要中列出了場景執(zhí)行情況、“StatisticsSummary（統(tǒng)計(jì)信息摘要）”、“TransactionSummary（事務(wù)摘要）”以及“HTTPResponsesSummary（HTTP響應(yīng)摘要）”等。以簡要的信息列出本次測試結(jié)果。圖1-2性能測試結(jié)果摘要圖場景執(zhí)行情況該部分給出了本次測試場景的名稱、結(jié)果存放路徑及場景的持續(xù)時(shí)間，如圖5-3所示。從該圖我們知道，本次測試從15:58:40開始，到16:29:42結(jié)束，共歷時(shí)31分2秒。與我們場景執(zhí)行計(jì)劃中設(shè)計(jì)的時(shí)間基本吻合。圖1-3場景執(zhí)行情況描述圖StatisticsSummary（統(tǒng)計(jì)信息摘要）該部分給出了場景執(zhí)行結(jié)束后并發(fā)數(shù)、總吞吐量、平均每秒吞吐量、總請求數(shù)、平均每秒請求數(shù)的統(tǒng)計(jì)值，如圖5-4所示。從該圖我們得知，本次測試運(yùn)行的最大并發(fā)數(shù)為7，總吞吐量為842,037,409字節(jié)，平均每秒的吞吐量為451,979字節(jié)，總的請求數(shù)為211,974，平均每秒的請求為113.781，對于吞吐量，單位時(shí)間內(nèi)吞吐量越大，說明服務(wù)器的處理能越好，而請求數(shù)僅表示客戶端向服務(wù)器發(fā)出的請求數(shù)，與吞吐量一般是成正比關(guān)系。圖1-4統(tǒng)計(jì)信息摘要圖TransactionSummary（事務(wù)摘要）該部分給出了場景執(zhí)行結(jié)束后相關(guān)Action的平均響應(yīng)時(shí)間、通過率等情況，如圖1-5所示。從該圖我們得到每個(gè)Action的平均響應(yīng)時(shí)間與業(yè)務(wù)成功率。注意：因?yàn)樵趫鼍暗摹癛un-timeSettings”的“Miscellaneous”選項(xiàng)中將每一個(gè)Action當(dāng)成了一個(gè)事務(wù)執(zhí)行，故這里的事務(wù)其實(shí)就是腳本中的Action。圖1-5事務(wù)摘要圖HTTPResponsesSummary（HTTP響應(yīng)摘要）該部分顯示在場景執(zhí)行過程中，每次HTTP請求發(fā)出去的狀態(tài)，是成功還是失敗，都在這里體現(xiàn)，如圖5-6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發(fā)出了211974次請求（與“統(tǒng)計(jì)信息摘要”中的“TotalHits”一致），其中“HTTP200”的是209811次，而“HTTP404”則有2163，說明在本次過程中，經(jīng)過發(fā)出的請求大部分都能正確響應(yīng)了，但還是有部分失敗了，但未影響測試結(jié)果，“HTTP200”表示請求被正確響應(yīng)，而“HTTP404”表示文件或者目錄未能找到。有朋友可能會問，這里出現(xiàn)了404的錯誤，為什么結(jié)果還都通過了。出現(xiàn)這樣問題的原因是腳本有些頁面的請求內(nèi)容并非關(guān)鍵點(diǎn)，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結(jié)果。圖1-6HTTP響應(yīng)摘要常用的HTTP狀態(tài)代碼如下：400無法解析此請求。401.1未經(jīng)授權(quán)：訪問由于憑據(jù)無效被拒絕。401.2未經(jīng)授權(quán):訪問由于服務(wù)器配置傾向使用替代身份驗(yàn)證方法而被拒絕。401.3未經(jīng)授權(quán)：訪問由于ACL對所請求資源的設(shè)置被拒絕。401.4未經(jīng)授權(quán)：Web服務(wù)器上安裝的篩選器授權(quán)失敗。401.5未經(jīng)授權(quán)：ISAPI/CGI應(yīng)用程序授權(quán)失敗。401.7未經(jīng)授權(quán)：由于Web服務(wù)器上的URL授權(quán)策略而拒絕訪問。403禁止訪問：訪問被拒絕。403.1禁止訪問：執(zhí)行訪問被拒絕。403.2禁止訪問：讀取訪問被拒絕。403.3禁止訪問：寫入訪問被拒絕。403.4禁止訪問：需要使用SSL查看該資源。403.5禁止訪問：需要使用SSL128查看該資源。403.6禁止訪問：客戶端的IP地址被拒絕。403.7禁止訪問：需要SSL客戶端證書。403.8禁止訪問：客戶端的DNS名稱被拒絕。403.9禁止訪問：太多客戶端試圖連接到Web服務(wù)器。403.10禁止訪問：Web服務(wù)器配置為拒絕執(zhí)行訪問。403.11禁止訪問：密碼已更改。403.12禁止訪問：服務(wù)器證書映射器拒絕了客戶端證書訪問。403.13禁止訪問：客戶端證書已在Web服務(wù)器上吊銷。403.14禁止訪問：在Web服務(wù)器上已拒絕目錄列表。403.15禁止訪問：Web服務(wù)器已超過客戶端訪問許可證限制。403.16禁止訪問：客戶端證書格式錯誤或未被Web服務(wù)器信任。403.17禁止訪問：客戶端證書已經(jīng)到期或者尚未生效。403.18禁止訪問：無法在當(dāng)前應(yīng)用程序池中執(zhí)行請求的URL。403.19禁止訪問：無法在該應(yīng)用程序池中為客戶端執(zhí)行CGI。403.20禁止訪問：Passport登錄失敗。404找不到文件或目錄。404.1文件或目錄未找到：網(wǎng)站無法在所請求的端口訪問。需要注意的是404.1錯誤只會出現(xiàn)在具有多個(gè)IP地址的計(jì)算機(jī)上。如果在特定IP地址/端口組合上收到客戶端請求，而且沒有將IP地址配置為在該特定的端口上偵聽，則IIS返回404.1HTTP錯誤。例如，如果一臺計(jì)算機(jī)有兩個(gè)IP地址，而只將其中一個(gè)IP地址配置為在端口80上偵聽，則另一個(gè)IP地址從端口80收到的任何請求都將導(dǎo)致IIS返回404.1錯誤。只應(yīng)在此服務(wù)級別設(shè)置該錯誤，因?yàn)橹挥挟?dāng)服務(wù)器上使用多個(gè)IP地址時(shí)才會將它返回給客戶端。404.2文件或目錄無法找到：鎖定策略禁止該請求。404.3文件或目錄無法找到：MIME映射策略禁止該請求。405用于訪問該頁的HTTP動作未被許可。406客戶端瀏覽器不接受所請求頁面的MIME類型。407Web服務(wù)器需要初始的代理驗(yàn)證。410文件已刪除。412客戶端設(shè)置的前提條件在Web服務(wù)器上評估時(shí)失敗。414請求URL太大，因此在Web服務(wù)器上不接受該URL。500服務(wù)器內(nèi)部錯誤。500.11服務(wù)器錯誤：Web服務(wù)器上的應(yīng)用程序正在關(guān)閉。500.12服務(wù)器錯誤：Web服務(wù)器上的應(yīng)用程序正在重新啟動。500.13服務(wù)器錯誤：Web服務(wù)器太忙。500.14服務(wù)器錯誤：服務(wù)器上的無效應(yīng)用程序配置。500.15服務(wù)器錯誤：不允許直接請求GLOBAL.ASA。500.16服務(wù)器錯誤：UNC授權(quán)憑據(jù)不正確。500.17服務(wù)器錯誤：URL授權(quán)存儲無法找到。500.18服務(wù)器錯誤：URL授權(quán)存儲無法打開。500.19服務(wù)器錯誤：該文件的數(shù)據(jù)在配置數(shù)據(jù)庫中配置不正確。500.20服務(wù)器錯誤：URL授權(quán)域無法找到。500100內(nèi)部服務(wù)器錯誤：ASP錯誤。501標(biāo)題值指定的配置沒有執(zhí)行。502Web服務(wù)器作為網(wǎng)關(guān)或代理服務(wù)器時(shí)收到無效的響應(yīng)。并發(fā)數(shù)分析“RunningVusers（運(yùn)行的并發(fā)數(shù)）”顯示了在場景執(zhí)行過程中并發(fā)數(shù)的執(zhí)行情況。它們顯示Vuser的狀態(tài)、完成腳本的Vuser的數(shù)量以及集合統(tǒng)計(jì)信息，將這些圖與事務(wù)圖結(jié)合使用可以確定Vuser的數(shù)量對事務(wù)響應(yīng)時(shí)間產(chǎn)生的影響。圖1-7顯示了在OA系統(tǒng)考勤業(yè)務(wù)性能測試過程中Vusers運(yùn)行情況，從圖中我們可以看到，Vusers的運(yùn)行趨勢與我們場景執(zhí)行計(jì)劃中的設(shè)置是一樣，表明在場景執(zhí)行過程中，Vusers是按照我們預(yù)期的設(shè)置運(yùn)行的，沒有Vuser出現(xiàn)運(yùn)行錯誤，這樣從另一個(gè)側(cè)面說明我們的參數(shù)化設(shè)置是正確的，因?yàn)槭褂梦ㄒ粩?shù)進(jìn)行參數(shù)化設(shè)置，如果設(shè)置不正確，將會導(dǎo)致Vuser運(yùn)行錯誤。在腳本中我們加入了這樣一段代碼：if(atoi(lr_eval_string("{num}"))>0){lr_output_message("登錄成功，繼續(xù)執(zhí)行.");}else{lr_error_message("登錄失敗，退出測試");return-1;}上述代碼的意思是說，如果登錄失敗了，就退出腳本的迭代，那么什么原因可能會導(dǎo)致登錄失敗呢？就是我們前面參數(shù)化的設(shè)置，一旦Vuser分配不到正確的登錄賬號，就可能導(dǎo)致登錄失敗，從而引起Vuser停止運(yùn)行。所以，從圖5-7的表現(xiàn)，可以認(rèn)為參數(shù)化是沒有問題的。圖1-7運(yùn)行的并發(fā)數(shù)圖測試腳本中我們還使用了集合點(diǎn)，那么這里還可以看看集合點(diǎn)在場景執(zhí)行過程中的表現(xiàn)，點(diǎn)擊左邊的“NewGraph”，出現(xiàn)圖5-8，展開“Vusers”前的加號，雙擊“Rendezvous”，出現(xiàn)集合點(diǎn)的圖形后，點(diǎn)擊【Close】，關(guān)閉添加新圖界面。圖1-8添加集合點(diǎn)統(tǒng)計(jì)圖集合點(diǎn)的圖形如圖1-9所示，從圖中可以看到，所有用戶到達(dá)集合點(diǎn)后，立刻就釋放了。與之前設(shè)定的集合點(diǎn)策略設(shè)置“所有運(yùn)行用戶到達(dá)后釋放“是一致的。假設(shè)這樣的一種情況，Running的Vusers有10個(gè)，集合點(diǎn)策略設(shè)置是“所有運(yùn)行用戶到達(dá)后釋放”，而集合點(diǎn)圖形顯示的最大釋放Vusers是7個(gè)，那么就表示有些Vuser超時(shí)了，引起超時(shí)的原因可能是Vuser得到的響應(yīng)超時(shí)了，可以結(jié)合平均事務(wù)響應(yīng)時(shí)間再詳細(xì)分析原因。圖1-9集合點(diǎn)狀態(tài)圖我們本次測試RunningVusers與集合點(diǎn)是一致，說明整個(gè)場景執(zhí)行過程中，并發(fā)數(shù)用戶的執(zhí)行正確，OA系統(tǒng)測試服務(wù)器能夠應(yīng)付7個(gè)并發(fā)用戶的業(yè)務(wù)操作。響應(yīng)時(shí)間在性能測試要求中我們知道，有一項(xiàng)指標(biāo)是要求登錄、考勤業(yè)務(wù)操作的頁面響應(yīng)時(shí)間不超過3秒，那么本次測試是否達(dá)到了這個(gè)要求呢？我們先來看“AverageTransactionResponseTime（平均事務(wù)響應(yīng)時(shí)間圖）”（圖1-10），這張圖是平均事務(wù)響應(yīng)時(shí)間與結(jié)果摘要中的“TransactionSummary”合成的。圖1-10平均事務(wù)響應(yīng)時(shí)間圖從圖形下部我們可以看到，登錄部分對應(yīng)的Action是“submit_login”，考勤業(yè)務(wù)提交對應(yīng)的Action是“submit_sign”，他們的“AverageTime（平均響應(yīng)時(shí)間為）”分別是4.425秒與0.848秒，從這兩個(gè)數(shù)值來看，考勤業(yè)務(wù)的事務(wù)響應(yīng)時(shí)間0.848秒小于預(yù)期的3秒，達(dá)到了要求，而登錄是4.425秒，大于預(yù)期的3秒，不符合要求。這樣的結(jié)果是不正確的，因?yàn)樵诮y(tǒng)計(jì)的登錄業(yè)務(wù)的時(shí)候，我們沒有去除思考時(shí)間，所以，登錄功能的實(shí)際事務(wù)時(shí)間應(yīng)該是4.425秒-3秒=1.425秒，小于預(yù)期的3秒，故登錄業(yè)務(wù)的事務(wù)響應(yīng)時(shí)間也達(dá)到了我們的要求。在平時(shí)的性能測試活動中，統(tǒng)計(jì)結(jié)果的時(shí)候需要去掉思考時(shí)間，加上思考時(shí)間是為了真實(shí)的模擬用戶環(huán)境，統(tǒng)計(jì)結(jié)果中除去思考時(shí)間是為了更真實(shí)的反映服務(wù)器的處理能力，兩者并不矛盾。看完了“AverageTime”，我們再看“90PercentTime”，這個(gè)時(shí)間從某種程度來說，更準(zhǔn)確衡量了測試過程中各個(gè)事務(wù)的真實(shí)情況，表示90%的事務(wù)，服務(wù)器的響應(yīng)都維持在某個(gè)值附近，“AverageTime”值對于平均事務(wù)響應(yīng)時(shí)間變動趨勢很大的情況統(tǒng)計(jì)就不準(zhǔn)確了，比如有三個(gè)時(shí)間：1秒、5秒、12秒，則平均時(shí)間為6秒，而另外一種情況：5秒、6秒、7秒，平均時(shí)間也為6秒，顯然第二種比第一種要穩(wěn)定多了。所以，我們在查看平均事務(wù)響應(yīng)時(shí)間的時(shí)候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽上忽下的波動情況，取“AverageTime”與“90PercentTime”都可以，如果整體趨勢毫無規(guī)律，波動非常大，我們就不用“AverageTime”而使用“90PercentTime”可能更真實(shí)些。從圖5-10可以看出，所有Action平均事務(wù)響應(yīng)時(shí)間的趨勢都非常平滑，所以使用“AverageTime”與“90PercentTime”差別不是很大，用哪個(gè)都可以。這里是使用最常用的統(tǒng)計(jì)方法“90PercentTime”。登錄業(yè)務(wù)的“90PercentTime”是5.298秒-3秒（思考時(shí)間）=2.298秒，考勤業(yè)務(wù)的“90PercentTime”是1.469秒，沒有思考時(shí)間，那么就是實(shí)打?qū)嵉睦?。根?jù)上面的計(jì)算，本次測試結(jié)果記錄如表1所示。測試項(xiàng)目標(biāo)值實(shí)際值是否通過登錄業(yè)務(wù)響應(yīng)時(shí)間<=3秒2.298秒Y考勤業(yè)務(wù)響應(yīng)時(shí)間<=3秒1.469秒Y登錄業(yè)務(wù)成功率100%考勤業(yè)務(wù)成功率100%登錄業(yè)務(wù)總數(shù)30分鐘完成2000考勤業(yè)務(wù)總數(shù)30分鐘完成2000CPU使用率<75%內(nèi)存使用率<70%表1測試結(jié)果對照表一每秒點(diǎn)擊數(shù)“HitsperSecond（每秒點(diǎn)擊數(shù)）”反映了客戶端每秒鐘向服務(wù)器端提交的請求數(shù)量，如果客戶端發(fā)出的請求數(shù)量越多，與之相對的“AverageThroughput(bytes/second)”也應(yīng)該越大，并且發(fā)出的請求越多會對平均事務(wù)響應(yīng)時(shí)間造成影響，所以在測試過程中往往將這三者結(jié)合起來分析。圖1-11顯示的是“HitsperSecond”與“AverageThroughput(bytes/second)”的復(fù)合圖，從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說明服務(wù)器能及時(shí)的接受客戶端的請求，并能夠返回結(jié)果。如果“HitsperSecond”正常，而“AverageThroughput(bytes/second)”不正常，則表示服務(wù)器雖然能夠接受服務(wù)器的請求，但返回結(jié)果較慢，可能是程序處理緩慢。如果“HitsperSecond”不正常，則說明客戶端存在問題，那種問題一般是網(wǎng)絡(luò)引起的，或者錄制的腳本有問題，未能正確的模擬用戶的行為。具體問題具體分析，這里僅給出一些建議。圖1-11每秒點(diǎn)擊數(shù)與每秒吞吐量復(fù)合圖對于本次測試來說，“HitsperSecond”與“AverageThroughput(bytes/second)”都是正常的，而且整體表現(xiàn)還是不錯的。一般情況下，這兩種指標(biāo)用于性能調(diào)優(yōu)，比如給定了幾個(gè)條件，去檢測另外一個(gè)條件，用這兩個(gè)指標(biāo)衡量，往往起到很好的效果。比如要比較某兩種硬件平臺的優(yōu)劣，就可以使用相同的配置方法部署軟件系統(tǒng)，然后使用相同的腳本、場景設(shè)計(jì)、統(tǒng)計(jì)方法去分析，最終得出一個(gè)較優(yōu)的配置。業(yè)務(wù)成功率“業(yè)務(wù)成功率”這個(gè)指標(biāo)在很多系統(tǒng)中都提及到，比如電信的、金融的、企業(yè)資源管理的等等。舉個(gè)例子，我們樓下的建行，假如每天的業(yè)務(wù)類別是這樣的：20個(gè)開戶，5個(gè)銷戶，300個(gè)存款，500取款，100個(gè)匯款等，那么在做他們的營業(yè)系統(tǒng)測試時(shí)就需要考慮業(yè)務(wù)成功率了，一般不得低于98%。具體的業(yè)務(wù)成功率是什么意思呢？排除那些復(fù)雜的業(yè)務(wù)，比如異步處理的業(yè)務(wù)（移動的套卡開通就是異步的），業(yè)務(wù)成功率就是事務(wù)成功率，用戶一般把一個(gè)Aciton當(dāng)做一筆業(yè)務(wù)，在LoadRunner場景執(zhí)行中一筆交易稱為一個(gè)事務(wù)。所以，說業(yè)務(wù)成功率其實(shí)就是事務(wù)成功率、通過率的意思。在“TransactionSummary”中我們可以很明確的看到每個(gè)事務(wù)的執(zhí)行狀態(tài)，如圖1-12所示。圖1-12事務(wù)狀態(tài)統(tǒng)計(jì)圖從圖中可以看出，所有的Aciton都是綠色的，即表示為Passed，同時(shí)除了vuser_init與vuser_end兩個(gè)事務(wù)，其他的事務(wù)通過數(shù)為2163，也就表明在30分鐘的時(shí)間里，共完成了2163次登錄考勤業(yè)務(wù)操作。那么根據(jù)這些可以判斷本次測試登錄業(yè)務(wù)與考勤業(yè)務(wù)的成功率是100%，再次更新測試結(jié)果記錄表如表2所示。測試項(xiàng)目標(biāo)值實(shí)際值是否通過登錄業(yè)務(wù)響應(yīng)時(shí)間<=3秒2.298秒Y考勤業(yè)務(wù)響應(yīng)時(shí)間<=3秒1.469秒Y登錄業(yè)務(wù)成功率100%100%Y考勤業(yè)務(wù)成功率100%100%Y登錄業(yè)務(wù)總數(shù)30分鐘完成20002163Y考勤業(yè)務(wù)總數(shù)30分鐘完成20002163YCPU使用率<75%內(nèi)存使用率<70%表2測試結(jié)果對照表二系統(tǒng)資源系統(tǒng)資源圖顯示了在場景執(zhí)行過程中被監(jiān)控的機(jī)器系統(tǒng)資源使用情況，一般情況下監(jiān)控機(jī)器的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等各個(gè)方面。本次測試監(jiān)控的是測試服務(wù)器的CPU使用率與內(nèi)存使用率，以及處理器隊(duì)列長度，具體的數(shù)據(jù)如圖1-13所示。圖1-13測試服務(wù)器系統(tǒng)資源監(jiān)控結(jié)果圖從圖中可以看出，CPU使用率、可用物理內(nèi)存、CPU的隊(duì)列長度三個(gè)指標(biāo)的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、8.45，而測試服務(wù)器總的物理內(nèi)存為384M，那么內(nèi)存使用率為（384-83.456）/384=78.26%，根據(jù)本次性能測試要求的：CPU使用率不超過75%，物理內(nèi)存使用率不超過70%這兩點(diǎn)來看，內(nèi)存的使用率78.26%大于預(yù)期的70%，故內(nèi)存使用率不達(dá)標(biāo)。根據(jù)Windwos資源性能指標(biāo)的解釋，一般情況下，如果“ProcessorQueueLength（處理器隊(duì)列長度）”一直超過二，則可能表示處理器堵塞，我們這里監(jiān)控出來的數(shù)值是8.45，而且總體上保持平衡，那么由此推斷，測試服務(wù)器的CPU也可能是個(gè)瓶頸。同時(shí)在測試過程中，場景執(zhí)行到23分半鐘的時(shí)候，報(bào)出了錯誤！未找到引用源。的錯誤，意思是說被監(jiān)控的服務(wù)器當(dāng)前無法再進(jìn)行計(jì)數(shù)器數(shù)據(jù)的獲取了，所以，本次操作系統(tǒng)資源的監(jiān)控只得到了場景執(zhí)行的前23分半鐘的數(shù)據(jù)。這樣對本次測試結(jié)果有一定的影響。獲得上述數(shù)據(jù)后，最新的測試結(jié)果記錄表如表3所示。測試項(xiàng)目標(biāo)值實(shí)際值是否通過登錄業(yè)務(wù)響應(yīng)時(shí)間<=3秒2.298秒Y考勤業(yè)務(wù)響應(yīng)時(shí)間<=3秒1.469秒Y登錄業(yè)務(wù)成功率100%100%Y考勤業(yè)務(wù)成功率100%100%Y登錄業(yè)務(wù)總數(shù)30分鐘完成20002163Y考勤業(yè)務(wù)總數(shù)30分鐘完成20002163YCPU使用率<75%53.582%Y內(nèi)存使用率<70%78.26%N表3測試結(jié)果對照表三從上表數(shù)據(jù)來看，本次測試總體上已經(jīng)達(dá)到了預(yù)期的性能指標(biāo)，但從其他的數(shù)據(jù)，比如CPU的隊(duì)列長度、內(nèi)存使用率來看，被測服務(wù)器的硬件資源需要提升。網(wǎng)頁細(xì)分圖網(wǎng)頁細(xì)分圖可以評估頁面內(nèi)容是否影響事務(wù)響應(yīng)時(shí)間。使用網(wǎng)頁細(xì)分圖，可以分析網(wǎng)站上有問題的元素（例如下載很慢的圖像或打不開的鏈接）。我們這里查看一下網(wǎng)頁細(xì)分圖中的“PageDownloadTimeBreakdown”，點(diǎn)擊錯誤！未找到引用源。左邊的“NewGraph”，出現(xiàn)圖1-14，展開“WebPageDiagnostics”前的加號，雙擊“PageDownloadTimeBreakdown”，待出現(xiàn)“PageDownloadTimeBreakdown”監(jiān)控圖后，點(diǎn)擊【Close】按鈕關(guān)閉添加監(jiān)控圖界面。圖1-14添加網(wǎng)頁細(xì)分圖在監(jiān)控圖列表中，我們看到圖1-15，從圖中我們看到，在所有的頁面中，登錄后的用個(gè)人面頁面的下載時(shí)間最長。圖1-15網(wǎng)頁下載時(shí)間細(xì)分圖圖1-16詳細(xì)列出了每個(gè)頁面所消耗的時(shí)間分布，圖中每一個(gè)指標(biāo)含義見表4所示。該表由LoadRunner使用手冊提供。通過這些指標(biāo)的數(shù)據(jù)，我們可以輕易的判斷是哪個(gè)頁面、哪個(gè)請求導(dǎo)致了響應(yīng)時(shí)間變長，甚至響應(yīng)失敗。圖1-16oa.jsp頁面下載時(shí)間分布圖名稱描述ClientTime顯示因?yàn)g覽器思考時(shí)間或其他與客戶端有關(guān)的延遲而使客戶機(jī)上的請求發(fā)生延遲時(shí)，所經(jīng)過的平均時(shí)間。ConnectionTime顯示與包含指定URL的Web服務(wù)器建立初始連接所需的時(shí)間。連接度量是一個(gè)很好的網(wǎng)絡(luò)問題指示器。此外，它還可表明服務(wù)器是否對請求做出響應(yīng)。DNSResolutionTime顯示使用最近的DNS服務(wù)器將DNS名稱解析為IP地址所需的時(shí)間。DNS查找度量是指示DNS解析問題或DNS服務(wù)器問題的一個(gè)很好的指示器。ErrorTime顯示從發(fā)出HTTP請求到返回錯誤消息（僅限于HTTP錯誤）這期間經(jīng)過的平均時(shí)間。FirstBufferTime顯示從初始HTTP請求（通常為GET）到成功收回來自Web服務(wù)器的第一次緩沖時(shí)為止所經(jīng)過的時(shí)間。第一次緩沖度量是很好的Web服務(wù)器延遲和網(wǎng)絡(luò)滯后指示器。（注意：由于緩沖區(qū)大小最大為8K，因此第一次緩沖時(shí)間可能也就是完成元素下載所需的時(shí)間。）FTPAuthernticationTime顯示驗(yàn)證客戶端所用的時(shí)間。如果使用FTP，則服務(wù)器在開始處理客戶端命令之前，必須驗(yàn)證該客戶端。FTP驗(yàn)證度量僅適用于FTP協(xié)議通信ReceiveTime顯示從服務(wù)器收到最后一個(gè)字節(jié)并完成下載之前經(jīng)過的時(shí)間。接收度量是很好的網(wǎng)絡(luò)質(zhì)量指示器（查看用來計(jì)算接收速率的時(shí)間/大小比率）。SSLHandshakingTime顯示建立SSL連接（包括客戶端hello、服務(wù)器hello、客戶端公用密鑰傳輸、服務(wù)器證書傳輸和其他部分可選階段）所用的時(shí)間。此時(shí)刻后，客戶端和服務(wù)器之間的所有通信都被加密。SSL握手度量僅適用于HTTPS通信。表4網(wǎng)頁下載時(shí)間細(xì)分指標(biāo)說明對于本次測試，從網(wǎng)頁細(xì)分圖來看，基本上每個(gè)頁面的加載時(shí)間都是預(yù)期范圍內(nèi)，oa.jsp頁面因?yàn)榧闪擞脩舻膫€(gè)人工作平臺，需要檢索很多的數(shù)據(jù)，并合成了很多圖片，所以相應(yīng)的加載時(shí)間較長，這是正確的。Web服務(wù)器資源上述所有的監(jiān)控圖形LoadRunner都可以提供，但對于某些測試監(jiān)控圖來說，LoadRunner就沒有提供了，期望其新版支持這些功能，當(dāng)然想監(jiān)控Tomcat、Jboss或者其他的Web服務(wù)器可以SiteScope工具，這個(gè)工具配置較為復(fù)雜，根據(jù)個(gè)人需要吧。我這里監(jiān)控Tomcat使用的是ManageEngineApplicationsManager8的試用版，測試結(jié)束后得出Tomcat的JVM使用率如圖1-17所示。圖1-17TomcatJVM使用率監(jiān)視圖從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時(shí)共分配了100M左右的物理內(nèi)存給其，測試初期使用的JVM相對來說較少，我們的測試場景是從15:58:40開始，到16:29:42結(jié)束，共歷時(shí)31分2秒。從圖中看到，從16:00到16:30這個(gè)時(shí)間內(nèi)，也就是測試場景執(zhí)行期間，JVM的使用率不斷上升，并沒有在請求達(dá)到均衡狀態(tài)后也呈現(xiàn)一種平衡狀態(tài)，所以，從這點(diǎn)可以推斷，如果測試場景繼續(xù)執(zhí)行，或者加大并發(fā)數(shù)，最終必將導(dǎo)致