loadrunneroracle? 一、比較測試時間和實際運行時間
eg、設置了運行時間是30分鐘，但是，實際相差太大，實際運行的時間只有幾分鐘，這可能是什么原因導致沒有持續運行設定的時間長度？
??? 打印出業務處理時間，統計實際運行總時間，分析等待、間隔時間等


二、nmon分析
1、nmon分析查看
? 1）CPU： 16個CPU使用率都超過了95%以上，這個值說明你的CPU已經達到極限值，分析點：那個功能引起耗費CPU資源，哪個部分耗費時間比較長，建議將系統的日志打印出來，進一步分析，進而定位到代碼或是函數級別
? 2）mem
????? cached+memfree+buffers >7G 內存應該沒有問題
2、loadrunner oracle分析
1）SQL語句：
??? 查詢出比較耗費資源的SQL語句
2）監控日志中 opened? cursors current
?????? 打開的游標平均值在 1641 ，這值是不是過大了，過大了說明你的SQL語句可能執行過慢的。游標一直沒有得到釋放。
3）oracle 表索引
??? 檢索的功能，查詢的表基本上是固定的，查看一下索引是否合理的。
4）表數據量大小
??? 建議你分析一下oracle現在表的數據量是否過大，最好的數據是依據線上的數據庫的數據量分析


三.服務器資源監控指標

　　(目前通過top監察)

　　內存：

　　Linux資源監控中指標內存頁交換速率(Paging rate)，如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。

　　實際測試中，當并發點擊數出現突然劇增前后，內存的PR 值則居高25不下。說明目前測試的系統中內存存在瓶頸!

　　內存資源成為系統性能的瓶頸的征兆:

　　很高的換頁率(high pageout rate);

　　進程進入不活動狀態;

　　交換區所有磁盤的活動次數可高;

　　可高的全局系統CPU利用率;

　　內存不夠出錯(out of memory errors)

　　處理器：

　　Linux資源監控中指標CPU占用率持續超過80%(對該值的要求，根據具體應用和機器配置而要求不同，有資料表明95%)，表明瓶頸是CPU。

　　實際測試中，當并發點技數出現突然增加前后，cpu的占用率持續保持在86%以上!

　　說明，目前系統用應用的cpu也是測試的瓶頸!

　　CPU資源成為系統性能的瓶頸的征兆:

　　很慢的響應時間(slow response time)

　　CPU空閑時間為零(zero percent idle CPU)

　　過高的用戶占用CPU時間(high percent user CPU)

　　過高的系統占用CPU時間(high percent system CPU)

　　長時間的有很長的運行進程隊列(large run queue size sustained over time)

　　四.數據庫服務器

　　數據庫服務器目前測試觀察，當web服務器點擊率增大時，觀察mysql數據庫的最大連接數，仍未超過系統設置的最大連接數。所以，暫時未發現數據庫的瓶頸!

　　五.結論

　　以上報告分析中的數據、圖標均來自同一次測試。是在平時測試中挑出的一次現象比較明顯，比較利于觀察的作為分析案例。

　　根據以上綜合分析，當前測試環境下，當應用系統產生最大533.667的并發壓力。平均負載壓力114.352。根據分析，用戶在4個小時的 時候，并發數迅速增加前后的值在400左右!分析結果跟實際測試的硬件環境以及測試腳本有一定關系。同時，測試服務器的硬件配置和實際服務器的配置還有一 定的差距!
參考：http://bbs.51testing.com/thread-547806-1-1.html
http://tech.chinaunix.net/a2009/0602/581/000000581480_1.shtml ?

總結

以上是生活随笔為你收集整理的性能测试分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。