測(cè)試結(jié)果分析

LoadRunner性能測(cè)試結(jié)果分析是個(gè)復(fù)雜的過(guò)程，通常可以從結(jié)果摘要、并發(fā)數(shù)、平均事務(wù)響應(yīng)時(shí)間、每秒點(diǎn)擊數(shù)、業(yè)務(wù)成功率、系統(tǒng)資源、網(wǎng)頁(yè)細(xì)分圖、Web服務(wù)器資源、數(shù)據(jù)庫(kù)服務(wù)器資源等幾個(gè)方面分析，如圖1所示。性能測(cè)試結(jié)果分析的一個(gè)重要的原則是以性能測(cè)試的需求指標(biāo)為導(dǎo)向。我們回顧一下本次性能測(cè)試的目的，正如所列的指標(biāo)，本次測(cè)試的要求是驗(yàn)證在30分鐘內(nèi)完成2000次用戶登錄系統(tǒng)，然后進(jìn)行考勤業(yè)務(wù)，最后退出，在業(yè)務(wù)操作過(guò)程中頁(yè)面的響應(yīng)時(shí)間不超過(guò)3秒，并且服務(wù)器的CPU使用率、內(nèi)存使用率分別不超過(guò)75%、70%，那么按照所示的流程，我們開(kāi)始分析，看看本次測(cè)試是否達(dá)到了預(yù)期的性能指標(biāo)，其中又有哪些性能隱患，該如何解決。

性能測(cè)試結(jié)果分析流程圖

結(jié)果摘要

LoadRunner進(jìn)行場(chǎng)景測(cè)試結(jié)果收集后，首先顯示的該結(jié)果的一個(gè)摘要信息，如圖2所示。概要中列出了場(chǎng)景執(zhí)行情況、“StatisticsSummary（統(tǒng)計(jì)信息摘要）”、“TransactionSummary（事務(wù)摘要）”以及“HTTPResponsesSummary（HTTP響應(yīng)摘要）”等。以簡(jiǎn)要的信息列出本次測(cè)試結(jié)果。

性能測(cè)試結(jié)果摘要圖

場(chǎng)景執(zhí)行情況

該部分給出了本次測(cè)試場(chǎng)景的名稱、結(jié)果存放路徑及場(chǎng)景的持續(xù)時(shí)間，如圖3所示。從該圖我們知道，本次測(cè)試從15:58:40開(kāi)始，到16:29:42結(jié)束，共歷時(shí)31分2秒。與我們場(chǎng)景執(zhí)行計(jì)劃中設(shè)計(jì)的時(shí)間基本吻合。

場(chǎng)景執(zhí)行情況描述圖

StatisticsSummary（統(tǒng)計(jì)信息摘要）

該部分給出了場(chǎng)景執(zhí)行結(jié)束后并發(fā)數(shù)、總吞吐量、平均每秒吞吐量、總請(qǐng)求數(shù)、平均每秒請(qǐng)求數(shù)的統(tǒng)計(jì)值，如圖4所示。從該圖我們得知，本次測(cè)試運(yùn)行的最大并發(fā)數(shù)為7，總吞吐量為842,037,409字節(jié)，平均每秒的吞吐量為451,979字節(jié)，總的請(qǐng)求數(shù)為211,974，平均每秒的請(qǐng)求為113.781，對(duì)于吞吐量，單位時(shí)間內(nèi)吞吐量越大，說(shuō)明服務(wù)器的處理能越好，而請(qǐng)求數(shù)僅表示客戶端向服務(wù)器發(fā)出的請(qǐng)求數(shù)，與吞吐量一般是成正比關(guān)系。

統(tǒng)計(jì)信息摘要圖

TransactionSummary（事務(wù)摘要）

該部分給出了場(chǎng)景執(zhí)行結(jié)束后相關(guān)Action的平均響應(yīng)時(shí)間、通過(guò)率等情況，如圖5所示。從該圖我們得到每個(gè)Action的平均響應(yīng)時(shí)間與業(yè)務(wù)成功率。

注意：因?yàn)樵趫?chǎng)景的“Run-timeSettings”的“Miscellaneous”選項(xiàng)中將每一個(gè)Action當(dāng)成了一個(gè)事務(wù)執(zhí)行，故這里的事務(wù)其實(shí)就是腳本中的Action。

事務(wù)摘要圖

HTTPResponsesSummary（HTTP響應(yīng)摘要）

該部分顯示在場(chǎng)景執(zhí)行過(guò)程中，每次HTTP請(qǐng)求發(fā)出去的狀態(tài)，是成功還是失敗，都在這里體現(xiàn)，如圖6所示。從圖中可以看到，在本次測(cè)試過(guò)程中LoadRunner共模擬發(fā)出了211974次請(qǐng)求（與“統(tǒng)計(jì)信息摘要”中的“TotalHits”一致），其中“HTTP200”的是209811次，而“HTTP404”則有2163，說(shuō)明在本次過(guò)程中，經(jīng)過(guò)發(fā)出的請(qǐng)求大部分都能正確響應(yīng)了，但還是有部分失敗了，但未影響測(cè)試結(jié)果，“HTTP200”表示請(qǐng)求被正確響應(yīng)，而“HTTP404”表示文件或者目錄未能找到。有朋友可能會(huì)問(wèn)，這里出現(xiàn)了404的錯(cuò)誤，為什么結(jié)果還都通過(guò)了。出現(xiàn)這樣問(wèn)題的原因是腳本有些頁(yè)面的請(qǐng)求內(nèi)容并非關(guān)鍵點(diǎn)，比如可能請(qǐng)求先前的cookie信息，如果沒(méi)有就重新獲取，所以不會(huì)影響最終的測(cè)試結(jié)果。

HTTP響應(yīng)摘要

常用的HTTP狀態(tài)代碼如下：

• 400無(wú)法解析此請(qǐng)求。
• 401.1未經(jīng)授權(quán)：訪問(wèn)由于憑據(jù)無(wú)效被拒絕。
• 401.2未經(jīng)授權(quán):訪問(wèn)由于服務(wù)器配置傾向使用替代身份驗(yàn)證方法而被拒絕。
• 401.3未經(jīng)授權(quán)：訪問(wèn)由于ACL對(duì)所請(qǐng)求資源的設(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)策略而拒絕訪問(wèn)。
• 403禁止訪問(wèn)：訪問(wèn)被拒絕。
• 403.1禁止訪問(wèn)：執(zhí)行訪問(wèn)被拒絕。
• 403.2禁止訪問(wèn)：讀取訪問(wèn)被拒絕。
• 403.3禁止訪問(wèn)：寫(xiě)入訪問(wèn)被拒絕。
• 403.4禁止訪問(wèn)：需要使用SSL查看該資源。
• 403.5禁止訪問(wèn)：需要使用SSL128查看該資源。
• 403.6禁止訪問(wèn)：客戶端的IP地址被拒絕。
• 403.7禁止訪問(wèn)：需要SSL客戶端證書(shū)。
• 403.8禁止訪問(wèn)：客戶端的DNS名稱被拒絕。
• 403.9禁止訪問(wèn)：太多客戶端試圖連接到Web服務(wù)器。
• 403.10禁止訪問(wèn)：Web服務(wù)器配置為拒絕執(zhí)行訪問(wèn)。
• 403.11禁止訪問(wèn)：密碼已更改。
• 403.12禁止訪問(wèn)：服務(wù)器證書(shū)映射器拒絕了客戶端證書(shū)訪問(wèn)。
• 403.13禁止訪問(wèn)：客戶端證書(shū)已在Web服務(wù)器上吊銷。
• 403.14禁止訪問(wèn)：在Web服務(wù)器上已拒絕目錄列表。
• 403.15禁止訪問(wèn)：Web服務(wù)器已超過(guò)客戶端訪問(wèn)許可證限制。
• 403.16禁止訪問(wèn)：客戶端證書(shū)格式錯(cuò)誤或未被Web服務(wù)器信任。
• 403.17禁止訪問(wèn)：客戶端證書(shū)已經(jīng)到期或者尚未生效。
• 403.18禁止訪問(wèn)：無(wú)法在當(dāng)前應(yīng)用程序池中執(zhí)行請(qǐng)求的URL。
• 403.19禁止訪問(wèn)：無(wú)法在該應(yīng)用程序池中為客戶端執(zhí)行CGI。
• 403.20禁止訪問(wèn)：Passport登錄失敗。
• 404找不到文件或目錄。
• 404.1文件或目錄未找到：網(wǎng)站無(wú)法在所請(qǐng)求的端口訪問(wèn)。

需要注意的是404.1錯(cuò)誤只會(huì)出現(xiàn)在具有多個(gè)IP地址的計(jì)算機(jī)上。如果在特定IP地址/端口組合上收到客戶端請(qǐng)求，而且沒(méi)有將IP地址配置為在該特定的端口上偵聽(tīng)，則IIS返回404.1HTTP錯(cuò)誤。例如，如果一臺(tái)計(jì)算機(jī)有兩個(gè)IP地址，而只將其中一個(gè)IP地址配置為在端口80上偵聽(tīng)，則另一個(gè)IP地址從端口80收到的任何請(qǐng)求都將導(dǎo)致IIS返回404.1錯(cuò)誤。只應(yīng)在此服務(wù)級(jí)別設(shè)置該錯(cuò)誤，因?yàn)橹挥挟?dāng)服務(wù)器上使用多個(gè)IP地址時(shí)才會(huì)將它返回給客戶端。

• 404.2文件或目錄無(wú)法找到：鎖定策略禁止該請(qǐng)求。
• 404.3文件或目錄無(wú)法找到：MIME映射策略禁止該請(qǐng)求。
• 405用于訪問(wèn)該頁(yè)的HTTP動(dòng)作未被許可。
• 406客戶端瀏覽器不接受所請(qǐng)求頁(yè)面的MIME類型。
• 407Web服務(wù)器需要初始的代理驗(yàn)證。
• 410文件已刪除。
• 412客戶端設(shè)置的前提條件在Web服務(wù)器上評(píng)估時(shí)失敗。
• 414請(qǐng)求URL太大，因此在Web服務(wù)器上不接受該URL。
• 500服務(wù)器內(nèi)部錯(cuò)誤。
• 500.11服務(wù)器錯(cuò)誤：Web服務(wù)器上的應(yīng)用程序正在關(guān)閉。
• 500.12服務(wù)器錯(cuò)誤：Web服務(wù)器上的應(yīng)用程序正在重新啟動(dòng)。
• 500.13服務(wù)器錯(cuò)誤：Web服務(wù)器太忙。
• 500.14服務(wù)器錯(cuò)誤：服務(wù)器上的無(wú)效應(yīng)用程序配置。
• 500.15服務(wù)器錯(cuò)誤：不允許直接請(qǐng)求GLOBAL.ASA。
• 500.16服務(wù)器錯(cuò)誤：UNC授權(quán)憑據(jù)不正確。
• 500.17服務(wù)器錯(cuò)誤：URL授權(quán)存儲(chǔ)無(wú)法找到。
• 500.18服務(wù)器錯(cuò)誤：URL授權(quán)存儲(chǔ)無(wú)法打開(kāi)。
• 500.19服務(wù)器錯(cuò)誤：該文件的數(shù)據(jù)在配置數(shù)據(jù)庫(kù)中配置不正確。
• 500.20服務(wù)器錯(cuò)誤：URL授權(quán)域無(wú)法找到。
• 500100內(nèi)部服務(wù)器錯(cuò)誤：ASP錯(cuò)誤。
• 501標(biāo)題值指定的配置沒(méi)有執(zhí)行。
• 502Web服務(wù)器作為網(wǎng)關(guān)或代理服務(wù)器時(shí)收到無(wú)效的響應(yīng)。

并發(fā)數(shù)分析

“RunningVusers（運(yùn)行的并發(fā)數(shù)）”顯示了在場(chǎng)景執(zhí)行過(guò)程中并發(fā)數(shù)的執(zhí)行情況。它們顯示Vuser的狀態(tài)、完成腳本的Vuser的數(shù)量以及集合統(tǒng)計(jì)信息，將這些圖與事務(wù)圖結(jié)合使用可以確定Vuser的數(shù)量對(duì)事務(wù)響應(yīng)時(shí)間產(chǎn)生的影響。圖7顯示了在OA系統(tǒng)考勤業(yè)務(wù)性能測(cè)試過(guò)程中Vusers運(yùn)行情況，從圖中我們可以看到，Vusers的運(yùn)行趨勢(shì)與我們場(chǎng)景執(zhí)行計(jì)劃中的設(shè)置是一樣，表明在場(chǎng)景執(zhí)行過(guò)程中，Vusers是按照我們預(yù)期的設(shè)置運(yùn)行的，沒(méi)有Vuser出現(xiàn)運(yùn)行錯(cuò)誤，這樣從另一個(gè)側(cè)面說(shuō)明我們的參數(shù)化設(shè)置是正確的，因?yàn)槭褂梦ㄒ粩?shù)進(jìn)行參數(shù)化設(shè)置，如果設(shè)置不正確，將會(huì)導(dǎo)致Vuser運(yùn)行錯(cuò)誤。在腳本中我們加入了這樣一段代碼：

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

lr_output_message("登錄成功，繼續(xù)執(zhí)行.");

}

else{

lr_error_message("登錄失敗，退出測(cè)試");

return-1;

}

上述代碼的意思是說(shuō)，如果登錄失敗了，就退出腳本的迭代，那么什么原因可能會(huì)導(dǎo)致登錄失敗呢？就是我們前面參數(shù)化的設(shè)置，一旦Vuser分配不到正確的登錄賬號(hào)，就可能導(dǎo)致登錄失敗，從而引起Vuser停止運(yùn)行。所以，從圖7的表現(xiàn)，可以認(rèn)為參數(shù)化是沒(méi)有問(wèn)題的。

運(yùn)行的并發(fā)數(shù)圖

測(cè)試腳本中我們還使用了集合點(diǎn)，那么這里還可以看看集合點(diǎn)在場(chǎng)景執(zhí)行過(guò)程中的表現(xiàn)，點(diǎn)擊左邊的“NewGraph”，出現(xiàn)圖8，展開(kāi)“Vusers”前的加號(hào)，雙擊“Rendezvous”，出現(xiàn)集合點(diǎn)的圖形后，點(diǎn)擊【Close】，關(guān)閉添加新圖界面。

添加集合點(diǎn)統(tǒng)計(jì)圖

集合點(diǎn)的圖形如圖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ì)分析原因。

集合點(diǎn)狀態(tài)圖

我們本次測(cè)試RunningVusers與集合點(diǎn)是一致，說(shuō)明整個(gè)場(chǎng)景執(zhí)行過(guò)程中，并發(fā)數(shù)用戶的執(zhí)行正確，OA系統(tǒng)測(cè)試服務(wù)器能夠應(yīng)付7個(gè)并發(fā)用戶的業(yè)務(wù)操作。

響應(yīng)時(shí)間

在性能測(cè)試要求中我們知道，有一項(xiàng)指標(biāo)是要求登錄、考勤業(yè)務(wù)操作的頁(yè)面響應(yīng)時(shí)間不超過(guò)3秒，那么本次測(cè)試是否達(dá)到了這個(gè)要求呢？我們先來(lái)看“AverageTransactionResponseTime（平均事務(wù)響應(yīng)時(shí)間圖）”（圖10），這張圖是平均事務(wù)響應(yīng)時(shí)間與結(jié)果摘要中的“TransactionSummary”合成的。

平均事務(wù)響應(yīng)時(shí)間圖

從圖形下部我們可以看到，登錄部分對(duì)應(yīng)的Action是“submit_login”，考勤業(yè)務(wù)提交對(duì)應(yīng)的Action是“submit_sign”，他們的“AverageTime（平均響應(yīng)時(shí)間為）”分別是4.425秒與0.848秒，從這兩個(gè)數(shù)值來(lái)看，考勤業(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í)候，我們沒(méi)有去除思考時(shí)間，所以，登錄功能的實(shí)際事務(wù)時(shí)間應(yīng)該是4.425秒-3秒=1.425秒，小于預(yù)期的3秒，故登錄業(yè)務(wù)的事務(wù)響應(yīng)時(shí)間也達(dá)到了我們的要求。在平時(shí)的性能測(cè)試活動(dòng)中，統(tǒng)計(jì)結(jié)果的時(shí)候需要去掉思考時(shí)間，加上思考時(shí)間是為了真實(shí)的模擬用戶環(huán)境，統(tǒng)計(jì)結(jié)果中除去思考時(shí)間是為了更真實(shí)的反映服務(wù)器的處理能力，兩者并不矛盾。

看完了“AverageTime”，我們?cè)倏?ldquo;90PercentTime”，這個(gè)時(shí)間從某種程度來(lái)說(shuō)，更準(zhǔn)確衡量了測(cè)試過(guò)程中各個(gè)事務(wù)的真實(shí)情況，表示90%的事務(wù)，服務(wù)器的響應(yīng)都維持在某個(gè)值附近，“AverageTime”值對(duì)于平均事務(wù)響應(yīng)時(shí)間變動(dòng)趨勢(shì)很大的情況統(tǒng)計(jì)就不準(zhǔn)確了，比如有三個(gè)時(shí)間：1秒、5秒、12秒，則平均時(shí)間為6秒，而另外一種情況：5秒、6秒、7秒，平均時(shí)間也為6秒，顯然第二種比第一種要穩(wěn)定多了。所以，我們?cè)诓榭雌骄聞?wù)響應(yīng)時(shí)間的時(shí)候，先看整體曲線走勢(shì)，如果整體趨勢(shì)比較平滑，沒(méi)有忽上忽下的波動(dòng)情況，取“AverageTime”與“90PercentTime”都可以，如果整體趨勢(shì)毫無(wú)規(guī)律，波動(dòng)非常大，我們就不用“AverageTime”而使用“90PercentTime”可能更真實(shí)些。

從圖10可以看出，所有Action平均事務(wù)響應(yīng)時(shí)間的趨勢(shì)都非常平滑，所以使用“AverageTime”與“90PercentTime”差別不是很大，用哪個(gè)都可以。這里是使用最常用的統(tǒng)計(jì)方法“90PercentTime”。登錄業(yè)務(wù)的“90PercentTime”是5.298秒-3秒（思考時(shí)間）=2.298秒，考勤業(yè)務(wù)的“90PercentTime”是1.469秒，沒(méi)有思考時(shí)間，那么就是實(shí)打?qū)嵉睦病８鶕?jù)上面的計(jì)算，本次測(cè)試結(jié)果記錄如表1所示。

測(cè)試結(jié)果對(duì)照表一

每秒點(diǎn)擊數(shù)

HitsperSecond（每秒點(diǎn)擊數(shù)）”反映了客戶端每秒鐘向服務(wù)器端提交的請(qǐng)求數(shù)量，如果客戶端發(fā)出的請(qǐng)求數(shù)量越多，與之相對(duì)的“AverageThroughput(bytes/second)”也應(yīng)該越大，并且發(fā)出的請(qǐng)求越多會(huì)對(duì)平均事務(wù)響應(yīng)時(shí)間造成影響，所以在測(cè)試過(guò)程中往往將這三者結(jié)合起來(lái)分析。圖11顯示的是“HitsperSecond”與“AverageThroughput(bytes/second)”的復(fù)合圖，從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說(shuō)明服務(wù)器能及時(shí)的接受客戶端的請(qǐng)求，并能夠返回結(jié)果。如果“HitsperSecond”正常，而“AverageThroughput(bytes/second)”不正常，則表示服務(wù)器雖然能夠接受服務(wù)器的請(qǐng)求，但返回結(jié)果較慢，可能是程序處理緩慢。如果“HitsperSecond”不正常，則說(shuō)明客戶端存在問(wèn)題，那種問(wèn)題一般是網(wǎng)絡(luò)引起的，或者錄制的腳本有問(wèn)題，未能正確的模擬用戶的行為。具體問(wèn)題具體分析，這里僅給出一些建議。

每秒點(diǎn)擊數(shù)與每秒吞吐量復(fù)合圖

對(duì)于本次測(cè)試來(lái)說(shuō)，“HitsperSecond”與“AverageThroughput(bytes/second)”都是正常的，而且整體表現(xiàn)還是不錯(cuò)的。

一般情況下，這兩種指標(biāo)用于性能調(diào)優(yōu)，比如給定了幾個(gè)條件，去檢測(cè)另外一個(gè)條件，用這兩個(gè)指標(biāo)衡量，往往起到很好的效果。比如要比較某兩種硬件平臺(tái)的優(yōu)劣，就可以使用相同的配置方法部署軟件系統(tǒng)，然后使用相同的腳本、場(chǎng)景設(shè)計(jì)、統(tǒng)計(jì)方法去分析，最終得出一個(gè)較優(yōu)的配置。

業(yè)務(wù)成功率

“業(yè)務(wù)成功率”這個(gè)指標(biāo)在很多系統(tǒng)中都提及到，比如電信的、金融的、企業(yè)資源管理的等等。舉個(gè)例子，我們樓下的建行，假如每天的業(yè)務(wù)類別是這樣的：20個(gè)開(kāi)戶，5個(gè)銷戶，300個(gè)存款，500取款，100個(gè)匯款等，那么在做他們的營(yíng)業(yè)系統(tǒng)測(cè)試時(shí)就需要考慮業(yè)務(wù)成功率了，一般不得低于98%。具體的業(yè)務(wù)成功率是什么意思呢？排除那些復(fù)雜的業(yè)務(wù)，比如異步處理的業(yè)務(wù)（移動(dòng)的套卡開(kāi)通就是異步的），業(yè)務(wù)成功率就是事務(wù)成功率，用戶一般把一個(gè)Aciton當(dāng)做一筆業(yè)務(wù)，在LoadRunner場(chǎng)景執(zhí)行中一筆交易稱為一個(gè)事務(wù)。所以，說(shuō)業(yè)務(wù)成功率其實(shí)就是事務(wù)成功率、通過(guò)率的意思。在“TransactionSummary”中我們可以很明確的看到每個(gè)事務(wù)的執(zhí)行狀態(tài)，如圖12所示。

事務(wù)狀態(tài)統(tǒng)計(jì)圖

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

測(cè)試結(jié)果對(duì)照表二

系統(tǒng)資源

系統(tǒng)資源圖顯示了在場(chǎng)景執(zhí)行過(guò)程中被監(jiān)控的機(jī)器系統(tǒng)資源使用情況，一般情況下監(jiān)控機(jī)器的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等各個(gè)方面。本次測(cè)試監(jiān)控的是測(cè)試服務(wù)器的CPU使用率與內(nèi)存使用率，以及處理器隊(duì)列長(zhǎng)度，具體的數(shù)據(jù)如圖13所示。

測(cè)試服務(wù)器系統(tǒng)資源監(jiān)控結(jié)果圖

從圖中可以看出，CPU使用率、可用物理內(nèi)存、CPU的隊(duì)列長(zhǎng)度三個(gè)指標(biāo)的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、8.45，而測(cè)試服務(wù)器總的物理內(nèi)存為384M，那么內(nèi)存使用率為（384-83.456）/384=78.26%，根據(jù)本次性能測(cè)試要求的：CPU使用率不超過(guò)75%，物理內(nèi)存使用率不超過(guò)70%這兩點(diǎn)來(lái)看，內(nèi)存的使用率78.26%大于預(yù)期的70%，故內(nèi)存使用率不達(dá)標(biāo)。根據(jù)Windwos資源性能指標(biāo)的解釋，一般情況下，如果“ProcessorQueueLength（處理器隊(duì)列長(zhǎng)度）”一直超過(guò)二，則可能表示處理器堵塞，我們這里監(jiān)控出來(lái)的數(shù)值是8.45，而且總體上保持平衡，那么由此推斷，測(cè)試服務(wù)器的CPU也可能是個(gè)瓶頸。同時(shí)在測(cè)試過(guò)程中，場(chǎng)景執(zhí)行到23分半鐘的時(shí)候，報(bào)出了錯(cuò)誤！未找到引用源。的錯(cuò)誤，意思是說(shuō)被監(jiān)控的服務(wù)器當(dāng)前無(wú)法再進(jìn)行計(jì)數(shù)器數(shù)據(jù)的獲取了，所以，本次操作系統(tǒng)資源的監(jiān)控只得到了場(chǎng)景執(zhí)行的前23分半鐘的數(shù)據(jù)。這樣對(duì)本次測(cè)試結(jié)果有一定的影響。

獲得上述數(shù)據(jù)后，最新的測(cè)試結(jié)果記錄表如表3所示。

測(cè)試結(jié)果對(duì)照表三

從上表數(shù)據(jù)來(lái)看，本次測(cè)試總體上已經(jīng)達(dá)到了預(yù)期的性能指標(biāo)，但從其他的數(shù)據(jù)，比如CPU的隊(duì)列長(zhǎng)度、內(nèi)存使用率來(lái)看，被測(cè)服務(wù)器的硬件資源需要提升。

網(wǎng)頁(yè)細(xì)分圖

網(wǎng)頁(yè)細(xì)分圖可以評(píng)估頁(yè)面內(nèi)容是否影響事務(wù)響應(yīng)時(shí)間。使用網(wǎng)頁(yè)細(xì)分圖，可以分析網(wǎng)站上有問(wèn)題的元素（例如下載很慢的圖像或打不開(kāi)的鏈接）。

我們這里查看一下網(wǎng)頁(yè)細(xì)分圖中的“PageDownloadTimeBreakdown”，點(diǎn)擊錯(cuò)誤！未找到引用源。左邊的“NewGraph”，出現(xiàn)圖14，展開(kāi)“WebPageDiagnostics”前的加號(hào)，雙擊“PageDownloadTimeBreakdown”，待出現(xiàn)“PageDownloadTimeBreakdown”監(jiān)控圖后，點(diǎn)擊【Close】按鈕關(guān)閉添加監(jiān)控圖界面。

添加網(wǎng)頁(yè)細(xì)分圖

在監(jiān)控圖列表中，我們看到圖15，從圖中我們看到，在所有的頁(yè)面中，登錄后的用個(gè)人面頁(yè)面“//192.168.0.52:8080/oa/oa.jsp”的下載時(shí)間最長(zhǎng)。

網(wǎng)頁(yè)下載時(shí)間細(xì)分圖

圖16詳細(xì)列出了每個(gè)頁(yè)面所消耗的時(shí)間分布，圖中每一個(gè)指標(biāo)含義見(jiàn)表4所示。該表由LoadRunner使用手冊(cè)提供。通過(guò)這些指標(biāo)的數(shù)據(jù)，我們可以輕易的判斷是哪個(gè)頁(yè)面、哪個(gè)請(qǐng)求導(dǎo)致了響應(yīng)時(shí)間變長(zhǎng)，甚至響應(yīng)失敗。

oa.jsp頁(yè)面下載時(shí)間分布圖

網(wǎng)頁(yè)下載時(shí)間細(xì)分指標(biāo)說(shuō)明

對(duì)于本次測(cè)試，從網(wǎng)頁(yè)細(xì)分圖來(lái)看，基本上每個(gè)頁(yè)面的加載時(shí)間都是預(yù)期范圍內(nèi)，oa.jsp頁(yè)面因?yàn)榧闪擞脩舻膫€(gè)人工作平臺(tái)，需要檢索很多的數(shù)據(jù)，并合成了很多圖片，所以相應(yīng)的加載時(shí)間較長(zhǎng)，這是正確的。

Web服務(wù)器資源

上述所有的監(jiān)控圖形LoadRunner都可以提供，但對(duì)于某些測(cè)試監(jiān)控圖來(lái)說(shuō)，LoadRunner就沒(méi)有提供了，期望其新版支持這些功能，當(dāng)然想監(jiān)控Tomcat、Jboss或者其他的Web服務(wù)器可以SiteScope工具，這個(gè)工具配置較為復(fù)雜，根據(jù)個(gè)人需要吧。我這里監(jiān)控Tomcat使用的是ManageEngineApplicationsManager8的試用版，測(cè)試結(jié)束后得出Tomcat的JVM使用率如圖17所示。

TomcatJVM使用率監(jiān)視圖

從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時(shí)共分配了100M左右的物理內(nèi)存給其，測(cè)試初期使用的JVM相對(duì)來(lái)說(shuō)較少，我們的測(cè)試場(chǎng)景是從15:58:40開(kāi)始，到16:29:42結(jié)束，共歷時(shí)31分2秒。從圖中看到，從16:00到16:30這個(gè)時(shí)間內(nèi)，也就是測(cè)試場(chǎng)景執(zhí)行期間，JVM的使用率不斷上升，并沒(méi)有在請(qǐng)求達(dá)到均衡狀態(tài)后也呈現(xiàn)一種平衡狀態(tài)，所以，從這點(diǎn)可以推斷，如果測(cè)試場(chǎng)景繼續(xù)執(zhí)行，或者加大并發(fā)數(shù)，最終必將導(dǎo)致Tomcat內(nèi)存不夠用而報(bào)出“OutOfMemory”內(nèi)存溢出的錯(cuò)誤。在正常情況下，內(nèi)存的使用應(yīng)該與“HitperSecond”、“AverageThroughput(bytes/second)”等監(jiān)控圖的圖形走勢(shì)是一致的。

從上述過(guò)程可以得出一個(gè)結(jié)論，出現(xiàn)圖17中的問(wèn)題，可能有兩個(gè)原因：

1. Tomcat的內(nèi)存分配不足
2. 程序代碼有錯(cuò)誤，可能導(dǎo)致內(nèi)存泄露

解決方法：

1. 為Tomcat分配更多的內(nèi)存，如果是使用的catalina.sh或Catalina.bat啟動(dòng)的Tomcat，則可在這兩個(gè)文件中添加“SETCATALINA_OPTS=-Xms300m–Xmx300m”，如果使用的winnt服務(wù)方式啟動(dòng)的Tomcat，則可在“運(yùn)行”中輸入“regedit”進(jìn)入注冊(cè)表，然后在“HKEY_LOCAL_MACHINE-->SOFTWARE-->ApacheSoftwareFoundation-->ProcessRunner1.0-->Tomcat5-->Parameters”修改兩個(gè)屬性，一個(gè)是JvmMs，另外一個(gè)是JvmMx，如圖18所示。
2. 檢查程序代碼，使用一些內(nèi)存泄露檢查工具進(jìn)行清查。
   
    

   修改Tocat的JVM數(shù)據(jù)

數(shù)據(jù)庫(kù)服務(wù)器資源

數(shù)據(jù)庫(kù)服務(wù)器資源監(jiān)控相對(duì)來(lái)說(shuō)就復(fù)雜的多了，現(xiàn)在常用的數(shù)據(jù)有Mysql、SQLServer、Oracle、DB2等，LoadRunner提供對(duì)后面幾種數(shù)據(jù)庫(kù)的監(jiān)控方法，但對(duì)Mysql沒(méi)有提供對(duì)應(yīng)的監(jiān)控方法。他不提供，咱們就自己找監(jiān)控工具，我這里使用的是Spotlight，該工具監(jiān)控?cái)?shù)據(jù)庫(kù)的好處是配置連接簡(jiǎn)單，不僅能監(jiān)控?cái)?shù)據(jù)庫(kù)，還能監(jiān)控操作系統(tǒng)的資源，監(jiān)控結(jié)果直觀明了。錯(cuò)誤！未找到引用源。顯示了Mysql數(shù)據(jù)庫(kù)在場(chǎng)景執(zhí)行過(guò)程中SQL語(yǔ)句的執(zhí)行情況，從圖中可以看到，“Selects（查詢）”與“Inserts（插入）”兩種語(yǔ)句執(zhí)行的趨勢(shì)在場(chǎng)景執(zhí)行過(guò)程中是比較平滑，并且測(cè)試中沒(méi)有錯(cuò)誤發(fā)現(xiàn)，也就說(shuō)明在處理相關(guān)業(yè)務(wù)時(shí)Mysql的處理是正常的。假如這兩種SQL語(yǔ)句任何一個(gè)出現(xiàn)波動(dòng)很大的情況，就可以推出在場(chǎng)景執(zhí)行過(guò)程中存在頁(yè)面錯(cuò)誤，因?yàn)檫@些語(yǔ)句不執(zhí)行，就表明某些頁(yè)面未被加載或者某些功能未被使用。在本次測(cè)試中，OA系統(tǒng)的“oa.jsp”頁(yè)面有大量的“Selects（查詢）”語(yǔ)句，而考勤操作則是“Inserts（插入）”，所以，只要有一方出問(wèn)題，必然表示測(cè)試過(guò)程中存在頁(yè)面打不開(kāi)或者考勤不成功的錯(cuò)誤。

通過(guò)前面的分析，在查看"錯(cuò)誤！未找到引用源。"中的SQL語(yǔ)句執(zhí)行狀態(tài)，本次測(cè)試在頁(yè)面訪問(wèn)、功能執(zhí)行方面是沒(méi)有問(wèn)題的。

原文轉(zhuǎn)載自：螞蟻互聯(lián)