測試結(jié)果分析

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

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

結(jié)果摘要

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

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

場景執(zhí)行情況

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

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

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

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

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

TransactionSummary（事務(wù)摘要）

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

注意：因為在場景的“Run-timeSettings”的“Miscellaneous”選項中將每一個Action當(dāng)成了一個事務(wù)執(zhí)行，故這里的事務(wù)其實就是腳本中的Action。

事務(wù)摘要圖

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

該部分顯示在場景執(zhí)行過程中，每次HTTP請求發(fā)出去的狀態(tài)，是成功還是失敗，都在這里體現(xiàn)，如圖6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發(fā)出了211974次請求（與“統(tǒng)計信息摘要”中的“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)鍵點，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結(jié)果。

HTTP響應(yīng)摘要

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

• 400無法解析此請求。
• 401.1未經(jīng)授權(quán)：訪問由于憑據(jù)無效被拒絕。
• 401.2未經(jīng)授權(quán):訪問由于服務(wù)器配置傾向使用替代身份驗證方法而被拒絕。
• 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)在具有多個IP地址的計算機(jī)上。如果在特定IP地址/端口組合上收到客戶端請求，而且沒有將IP地址配置為在該特定的端口上偵聽，則IIS返回404.1HTTP錯誤。例如，如果一臺計算機(jī)有兩個IP地址，而只將其中一個IP地址配置為在端口80上偵聽，則另一個IP地址從端口80收到的任何請求都將導(dǎo)致IIS返回404.1錯誤。只應(yīng)在此服務(wù)級別設(shè)置該錯誤，因為只有當(dāng)服務(wù)器上使用多個IP地址時才會將它返回給客戶端。

• 404.2文件或目錄無法找到：鎖定策略禁止該請求。
• 404.3文件或目錄無法找到：MIME映射策略禁止該請求。
• 405用于訪問該頁的HTTP動作未被許可。
• 406客戶端瀏覽器不接受所請求頁面的MIME類型。
• 407Web服務(wù)器需要初始的代理驗證。
• 410文件已刪除。
• 412客戶端設(shè)置的前提條件在Web服務(wù)器上評估時失敗。
• 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ù)器時收到無效的響應(yīng)。

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

“RunningVusers（運(yùn)行的并發(fā)數(shù)）”顯示了在場景執(zhí)行過程中并發(fā)數(shù)的執(zhí)行情況。它們顯示Vuser的狀態(tài)、完成腳本的Vuser的數(shù)量以及集合統(tǒng)計信息，將這些圖與事務(wù)圖結(jié)合使用可以確定Vuser的數(shù)量對事務(wù)響應(yīng)時間產(chǎn)生的影響。圖7顯示了在OA系統(tǒng)考勤業(yè)務(wù)性能測試過程中Vusers運(yùn)行情況，從圖中我們可以看到，Vusers的運(yùn)行趨勢與我們場景執(zhí)行計劃中的設(shè)置是一樣，表明在場景執(zhí)行過程中，Vusers是按照我們預(yù)期的設(shè)置運(yùn)行的，沒有Vuser出現(xiàn)運(yùn)行錯誤，這樣從另一個側(cè)面說明我們的參數(shù)化設(shè)置是正確的，因為使用唯一數(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)行。所以，從圖7的表現(xiàn)，可以認(rèn)為參數(shù)化是沒有問題的。

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

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

添加集合點統(tǒng)計圖

集合點的圖形如圖9所示，從圖中可以看到，所有用戶到達(dá)集合點后，立刻就釋放了。與之前設(shè)定的集合點策略設(shè)置“所有運(yùn)行用戶到達(dá)后釋放“是一致的。假設(shè)這樣的一種情況，Running的Vusers有10個，集合點策略設(shè)置是“所有運(yùn)行用戶到達(dá)后釋放”，而集合點圖形顯示的最大釋放Vusers是7個，那么就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應(yīng)超時了，可以結(jié)合平均事務(wù)響應(yīng)時間再詳細(xì)分析原因。

集合點狀態(tài)圖

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

響應(yīng)時間

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

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

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

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

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

測試結(jié)果對照表一

每秒點擊數(shù)

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

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

對于本次測試來說，“HitsperSecond”與“AverageThroughput(bytes/second)”都是正常的，而且整體表現(xiàn)還是不錯的。

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

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

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

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

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

測試結(jié)果對照表二

系統(tǒng)資源

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

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

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

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

測試結(jié)果對照表三

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

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

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

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

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

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

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

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

oa.jsp頁面下載時間分布圖

網(wǎng)頁下載時間細(xì)分指標(biāo)說明

對于本次測試，從網(wǎng)頁細(xì)分圖來看，基本上每個頁面的加載時間都是預(yù)期范圍內(nèi)，oa.jsp頁面因為集成了用戶的個人工作平臺，需要檢索很多的數(shù)據(jù)，并合成了很多圖片，所以相應(yīng)的加載時間較長，這是正確的。

Web服務(wù)器資源

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

TomcatJVM使用率監(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的使用率不斷上升，并沒有在請求達(dá)到均衡狀態(tài)后也呈現(xiàn)一種平衡狀態(tài)，所以，從這點可以推斷，如果測試場景繼續(xù)執(zhí)行，或者加大并發(fā)數(shù)，最終必將導(dǎo)致Tomcat內(nèi)存不夠用而報出“OutOfMemory”內(nèi)存溢出的錯誤。在正常情況下，內(nèi)存的使用應(yīng)該與“HitperSecond”、“AverageThroughput(bytes/second)”等監(jiān)控圖的圖形走勢是一致的。

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

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

解決方法：

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

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

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

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

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

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