性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)

性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)

ID:38727122

大?。?37.00 KB

頁數(shù):10頁

時(shí)間:2019-06-18

性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)_第1頁
性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)_第2頁
性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)_第3頁
性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)_第4頁
性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)_第5頁
資源描述:

《性能測試監(jiān)控指標(biāo)技術(shù)總結(jié)》由會員上傳分享,免費(fèi)在線閱讀,更多相關(guān)內(nèi)容在教育資源-天天文庫。

1、1.性能測試設(shè)計(jì)(1)逐級加壓測試在本次性能測試過程中,除了以前使用的負(fù)載測試、壓力測試和疲勞強(qiáng)度測試等方式外,我方還設(shè)計(jì)了逐級加壓的性能測試場景。主要目的是在一個(gè)場景采用逐漸增加用戶數(shù)量的方法逐漸加大系統(tǒng)的壓力,檢測系統(tǒng)在壓力逐漸增加情況下的服務(wù)情況,更準(zhǔn)確地找出在用戶可接受的情況下系統(tǒng)能承受的最大用戶數(shù)和最佳用戶數(shù)量。該方式在實(shí)際使用中,達(dá)到效好的效果。下面結(jié)合移動項(xiàng)目的測試場景,對該測試方式進(jìn)行說明。在進(jìn)行逐級加壓的性能測試場景前應(yīng)先進(jìn)行負(fù)載或壓力測試,確定系統(tǒng)在大致達(dá)到某一數(shù)量級并發(fā)用戶時(shí)系統(tǒng)性能變得不可接受。然后以這個(gè)并發(fā)用戶數(shù)

2、下的最大響應(yīng)時(shí)間為逐級加壓場景的時(shí)間階梯。如在前面的測試中800用戶并發(fā)時(shí),系統(tǒng)出現(xiàn)了事務(wù)失敗,響應(yīng)時(shí)間最大為26秒左右,那么逐級加壓測試場景就可以設(shè)定為1-800用戶,每30秒增加一批用戶,每批增加的用戶數(shù)與要測試的時(shí)間長度和用戶需求要求的并發(fā)用戶精確程度有一定關(guān)系,如用戶要求測試結(jié)果精確在50用戶以內(nèi),那么就可以采用每30秒增加40個(gè)并發(fā)用戶數(shù)的方式,全部用戶登錄的時(shí)間約為(800用戶/40用戶)*30秒=600秒,再加上幾分鐘的全部并發(fā)用戶執(zhí)行時(shí)間,總體測試時(shí)間可以設(shè)計(jì)為10分鐘(600秒)+2分鐘(觀察運(yùn)行)=12分鐘。以移動項(xiàng)目

3、該場景的為例,測試結(jié)果如下圖圖7-4并發(fā)用戶數(shù)與響應(yīng)時(shí)間對照結(jié)果分析如下:系統(tǒng)在1-800用戶并發(fā)壓力逐漸加大的情況下,響應(yīng)時(shí)間逐漸變長(如圖7-4),根據(jù)2-5-10原則,可以推測,在現(xiàn)有系統(tǒng)軟件配置下,當(dāng)并發(fā)用戶在15(參考每秒請求數(shù)為5)以下時(shí),用戶鑒權(quán)基本可以2秒內(nèi)得到響應(yīng);當(dāng)并發(fā)用戶在100(參考每秒請求數(shù)為16)以下時(shí),用戶鑒權(quán)基本可以5秒內(nèi)得到響應(yīng);當(dāng)并發(fā)用戶在240(參考每秒請求數(shù)為23)以下時(shí),用戶鑒權(quán)基本可以10秒內(nèi)得到響應(yīng)(如圖7-4)。(1)項(xiàng)目監(jiān)控指標(biāo)本次性能測試系統(tǒng)架構(gòu)是典型的Unix+Weblogic+Ora

4、cle形式,監(jiān)控指標(biāo)較為全面并給出了性能分析的參考值,可以作以后此類項(xiàng)目的參考基準(zhǔn):分類指標(biāo)名稱描述單位參考值外部表現(xiàn)事務(wù)響應(yīng)時(shí)間客戶端發(fā)送請求,服務(wù)器返回最后(或者第)一個(gè)字節(jié)的時(shí)間秒無事務(wù)成功數(shù)指定時(shí)間內(nèi)成功完成的事務(wù)數(shù)量筆無事務(wù)失敗數(shù)筆無指定時(shí)間內(nèi)完成失敗的事務(wù)數(shù)量每秒請求次數(shù)每秒發(fā)送的請求次數(shù)次/秒無吞吐量每秒系統(tǒng)流入流出的字節(jié)數(shù)字節(jié)/秒無UnixCPUutilizationCPU占用率%<80AverageLoadCPU處理等待線程數(shù)個(gè)<0.7*CPU個(gè)數(shù)*核數(shù)Pagingrate內(nèi)存頁交換率頁/秒<80Diskrate磁盤處理

5、交換率MContextswitchesrate線程切換率次/秒<5000*CPU個(gè)數(shù)Oracle高速緩存區(qū)命中率高速緩存區(qū)命中率%>90庫快存命中率庫快存命中率%>90共享區(qū)庫緩存區(qū)命中率%>99共享區(qū)庫緩存區(qū)命中率SGA中字典緩沖區(qū)的命中率SGA中字典緩沖區(qū)的命中率%>85回滾段的爭用回滾段的爭用%<1SGA中重做日志緩存區(qū)的命中率SGA中重做日志緩存區(qū)的命中率%<1監(jiān)控內(nèi)存和硬盤的排序比率監(jiān)控內(nèi)存和硬盤的排序比率%<10當(dāng)前打開游標(biāo)總數(shù)當(dāng)前打開游標(biāo)總數(shù)個(gè)<300Weblogic線程等待隊(duì)列長度線程等待隊(duì)列長度個(gè)<50Java堆可用百分

6、比Java堆可用百分比%>30ServerRutime/JVMRuntime/HeapSizeCurrentBytes當(dāng)前堆大小ServerRutime/JVMRuntime/HeapFreeCurrent空閑堆大小BytesServerRutime/JDBCConnectionPool/WaitForConnectionCount等待連接數(shù)ServerRutime/JDBCConnectionPool/MaxCacapcity連接池最大容量ServerRutime/JDBCConnectionPool/WaitForSecondHigh

7、Count連接最大等待時(shí)間秒ServerRutime/JDBCConnectionPool/ActiveConnectionsCount活動連接數(shù)ServerRutime/ExecuteQueduRuntime/ExecuteThreadCurrentIdleCount空閑線程數(shù)ServerRutime/ExecuteQueduRuntime/PendingRequestOldestTime最長請求等待時(shí)間ServerRutime/ExecuteQueduRuntime/PendingRequestCurrentCoun等待請求數(shù)量(1)

8、自定義監(jiān)控指標(biāo)由于Loadrunner工具自身定義的Oracle監(jiān)控指標(biāo)較少,不能滿足進(jìn)行詳細(xì)結(jié)果分析的要求。我方在對Loadrunner的結(jié)果計(jì)數(shù)器文件進(jìn)行了修改,自定義了一系列監(jiān)控指標(biāo)。完

當(dāng)前文檔最多預(yù)覽五頁,下載文檔查看全文

此文檔下載收益歸作者所有

當(dāng)前文檔最多預(yù)覽五頁,下載文檔查看全文
溫馨提示:
1. 部分包含數(shù)學(xué)公式或PPT動畫的文件,查看預(yù)覽時(shí)可能會顯示錯(cuò)亂或異常,文件下載后無此問題,請放心下載。
2. 本文檔由用戶上傳,版權(quán)歸屬用戶,天天文庫負(fù)責(zé)整理代發(fā)布。如果您對本文檔版權(quán)有爭議請及時(shí)聯(lián)系客服。
3. 下載前請仔細(xì)閱讀文檔內(nèi)容,確認(rèn)文檔內(nèi)容符合您的需求后進(jìn)行下載,若出現(xiàn)內(nèi)容與標(biāo)題不符可向本站投訴處理。
4. 下載文檔時(shí)可能由于網(wǎng)絡(luò)波動等原因無法下載或下載錯(cuò)誤,付費(fèi)完成后未能成功下載的用戶請聯(lián)系客服處理。