性能测试分析
loadrunneroracle?
一、比較測試時間和實際運行時間
eg、設置了運行時間是30分鐘,但是,實際相差太大,實際運行的時間只有幾分鐘,這可能是什么原因導致沒有持續(xù)運行設定的時間長度?
??? 打印出業(yè)務處理時間,統(tǒng)計實際運行總時間,分析等待、間隔時間等
二、nmon分析
1、nmon分析查看
? 1)CPU: 16個CPU使用率都超過了95%以上,這個值說明你的CPU已經(jīng)達到極限值,分析點:那個功能引起耗費CPU資源,哪個部分耗費時間比較長,建議將系統(tǒng)的日志打印出來,進一步分析,進而定位到代碼或是函數(shù)級別
? 2)mem
????? cached+memfree+buffers >7G 內存應該沒有問題
2、loadrunner oracle分析
1)SQL語句:
??? 查詢出比較耗費資源的SQL語句
2)監(jiān)控日志中 opened? cursors current
?????? 打開的游標平均值在 1641 ,這值是不是過大了,過大了說明你的SQL語句可能執(zhí)行過慢的。游標一直沒有得到釋放。
3)oracle 表索引
??? 檢索的功能,查詢的表基本上是固定的,查看一下索引是否合理的。
4)表數(shù)據(jù)量大小
??? 建議你分析一下oracle現(xiàn)在表的數(shù)據(jù)量是否過大,最好的數(shù)據(jù)是依據(jù)線上的數(shù)據(jù)庫的數(shù)據(jù)量分析
三.服務器資源監(jiān)控指標
(目前通過top監(jiān)察)
內存:
Linux資源監(jiān)控中指標內存頁交換速率(Paging rate),如果該值偶爾走高,表明當時有線程競爭內存。如果持續(xù)很高,則內存可能是瓶頸。也可能是內存訪問命中率低。
實際測試中,當并發(fā)點擊數(shù)出現(xiàn)突然劇增前后,內存的PR 值則居高25不下。說明目前測試的系統(tǒng)中內存存在瓶頸!
內存資源成為系統(tǒng)性能的瓶頸的征兆:
很高的換頁率(high pageout rate);
進程進入不活動狀態(tài);
交換區(qū)所有磁盤的活動次數(shù)可高;
可高的全局系統(tǒng)CPU利用率;
內存不夠出錯(out of memory errors)
處理器:
Linux資源監(jiān)控中指標CPU占用率持續(xù)超過80%(對該值的要求,根據(jù)具體應用和機器配置而要求不同,有資料表明95%),表明瓶頸是CPU。
實際測試中,當并發(fā)點技數(shù)出現(xiàn)突然增加前后,cpu的占用率持續(xù)保持在86%以上!
說明,目前系統(tǒng)用應用的cpu也是測試的瓶頸!
CPU資源成為系統(tǒng)性能的瓶頸的征兆:
很慢的響應時間(slow response time)
CPU空閑時間為零(zero percent idle CPU)
過高的用戶占用CPU時間(high percent user CPU)
過高的系統(tǒng)占用CPU時間(high percent system CPU)
長時間的有很長的運行進程隊列(large run queue size sustained over time)
四.數(shù)據(jù)庫服務器
數(shù)據(jù)庫服務器目前測試觀察,當web服務器點擊率增大時,觀察mysql數(shù)據(jù)庫的最大連接數(shù),仍未超過系統(tǒng)設置的最大連接數(shù)。所以,暫時未發(fā)現(xiàn)數(shù)據(jù)庫的瓶頸!
五.結論
以上報告分析中的數(shù)據(jù)、圖標均來自同一次測試。是在平時測試中挑出的一次現(xiàn)象比較明顯,比較利于觀察的作為分析案例。
根據(jù)以上綜合分析,當前測試環(huán)境下,當應用系統(tǒng)產(chǎn)生最大533.667的并發(fā)壓力。平均負載壓力114.352。根據(jù)分析,用戶在4個小時的 時候,并發(fā)數(shù)迅速增加前后的值在400左右!分析結果跟實際測試的硬件環(huán)境以及測試腳本有一定關系。同時,測試服務器的硬件配置和實際服務器的配置還有一 定的差距!
參考:http://bbs.51testing.com/thread-547806-1-1.html
http://tech.chinaunix.net/a2009/0602/581/000000581480_1.shtml ?
eg、設置了運行時間是30分鐘,但是,實際相差太大,實際運行的時間只有幾分鐘,這可能是什么原因導致沒有持續(xù)運行設定的時間長度?
??? 打印出業(yè)務處理時間,統(tǒng)計實際運行總時間,分析等待、間隔時間等
二、nmon分析
1、nmon分析查看
? 1)CPU: 16個CPU使用率都超過了95%以上,這個值說明你的CPU已經(jīng)達到極限值,分析點:那個功能引起耗費CPU資源,哪個部分耗費時間比較長,建議將系統(tǒng)的日志打印出來,進一步分析,進而定位到代碼或是函數(shù)級別
? 2)mem
????? cached+memfree+buffers >7G 內存應該沒有問題
2、loadrunner oracle分析
1)SQL語句:
??? 查詢出比較耗費資源的SQL語句
2)監(jiān)控日志中 opened? cursors current
?????? 打開的游標平均值在 1641 ,這值是不是過大了,過大了說明你的SQL語句可能執(zhí)行過慢的。游標一直沒有得到釋放。
3)oracle 表索引
??? 檢索的功能,查詢的表基本上是固定的,查看一下索引是否合理的。
4)表數(shù)據(jù)量大小
??? 建議你分析一下oracle現(xiàn)在表的數(shù)據(jù)量是否過大,最好的數(shù)據(jù)是依據(jù)線上的數(shù)據(jù)庫的數(shù)據(jù)量分析
三.服務器資源監(jiān)控指標
(目前通過top監(jiān)察)
內存:
Linux資源監(jiān)控中指標內存頁交換速率(Paging rate),如果該值偶爾走高,表明當時有線程競爭內存。如果持續(xù)很高,則內存可能是瓶頸。也可能是內存訪問命中率低。
實際測試中,當并發(fā)點擊數(shù)出現(xiàn)突然劇增前后,內存的PR 值則居高25不下。說明目前測試的系統(tǒng)中內存存在瓶頸!
內存資源成為系統(tǒng)性能的瓶頸的征兆:
很高的換頁率(high pageout rate);
進程進入不活動狀態(tài);
交換區(qū)所有磁盤的活動次數(shù)可高;
可高的全局系統(tǒng)CPU利用率;
內存不夠出錯(out of memory errors)
處理器:
Linux資源監(jiān)控中指標CPU占用率持續(xù)超過80%(對該值的要求,根據(jù)具體應用和機器配置而要求不同,有資料表明95%),表明瓶頸是CPU。
實際測試中,當并發(fā)點技數(shù)出現(xiàn)突然增加前后,cpu的占用率持續(xù)保持在86%以上!
說明,目前系統(tǒng)用應用的cpu也是測試的瓶頸!
CPU資源成為系統(tǒng)性能的瓶頸的征兆:
很慢的響應時間(slow response time)
CPU空閑時間為零(zero percent idle CPU)
過高的用戶占用CPU時間(high percent user CPU)
過高的系統(tǒng)占用CPU時間(high percent system CPU)
長時間的有很長的運行進程隊列(large run queue size sustained over time)
四.數(shù)據(jù)庫服務器
數(shù)據(jù)庫服務器目前測試觀察,當web服務器點擊率增大時,觀察mysql數(shù)據(jù)庫的最大連接數(shù),仍未超過系統(tǒng)設置的最大連接數(shù)。所以,暫時未發(fā)現(xiàn)數(shù)據(jù)庫的瓶頸!
五.結論
以上報告分析中的數(shù)據(jù)、圖標均來自同一次測試。是在平時測試中挑出的一次現(xiàn)象比較明顯,比較利于觀察的作為分析案例。
根據(jù)以上綜合分析,當前測試環(huán)境下,當應用系統(tǒng)產(chǎn)生最大533.667的并發(fā)壓力。平均負載壓力114.352。根據(jù)分析,用戶在4個小時的 時候,并發(fā)數(shù)迅速增加前后的值在400左右!分析結果跟實際測試的硬件環(huán)境以及測試腳本有一定關系。同時,測試服務器的硬件配置和實際服務器的配置還有一 定的差距!
參考:http://bbs.51testing.com/thread-547806-1-1.html
http://tech.chinaunix.net/a2009/0602/581/000000581480_1.shtml ?
總結
- 上一篇: dinic (最大流) 算法 讲解
- 下一篇: PHP5.4.3,有些插件不是你想用就能