性能瓶頸定位案例    《轉載》

被測系統介紹

　　被測系統為B/S結構，J2EE架構，應用服務器為Tomcat，數據庫為Oracle 10g。系統的使用對象為公司的內部人員，網絡環境為100兆局域網。

　　性能瓶頸描述

　　客戶反映訪問頁面時反應慢，并且出現部分請求失敗的現象。

　　通過對單用戶的網絡帶寬計算，排除網絡瓶頸。

　　解決思路

　　在應用服務器Tomcat植入dynaTrace Agent，Agent能7X24實時收集應用服務器的所有的Log，包括最終客戶端向Tomcat發送的Web Requests、Tomcat向DB請求的SQL語 句、DB執行完SQL語句的返回數據、Tomcat向最終客戶端發送的返回數據。dynaTrace Server智能分析dynaTrace Collector收集到的所有Agent捕獲的Log。通過dynaTrace Client實時查看監控信息，對被測系統進行性能瓶頸定位并分析。詳細的測試環境部署圖如下：

　　解決過程

　　1）通過Error快速定位瓶頸

　　對實時監控收集的Log進行分析。首先查看其事務流圖Transaction Flow。如圖2。Failed Transactions顯示失敗的事務及失敗事務數占總事務數的百分比。圖2顯示存在失敗的事務867個，占總事務數的3.17%。

　　對出現失敗的事務進行分析，首先查看失敗事務提示的Error Log，如圖3。說明存在4XX 、5XX Error，也有重要程序內部Log，具體Error見圖4、圖5、圖6。

　 　將收集的Error Log提交bug給開發人員。HTTP Response Code的Error詳情可以協助開發人員快速定位并修復有問題的URL。Important Loggings可以幫助開發人員快速定位程序出現問題的原因。如圖6顯示創建Socket 連接失敗，并提示確認相關Server已開啟或相關組件已正常運行。

　　2）快速定位瓶頸原因

　　在性能索引圖表快速鎖定響應時間長的性能索引。如圖7，事務響應時間最長的性能索引為/IOST/as.do，響應時間為40004.86ms。

　　分析性能索引的方法執行情況，可快速看到執行過程中出現了Exception。如圖8。

　　定位到出現Exception的源碼，如圖9。

　　針對響應時間最長的性能索 /IOST/as.do進行分析。鉆取性能索引/IOST/as.do 的Web Request，定位其相關的URL，如圖10。URL為http://172.16.200.61:8080/IOST/as.do，在瀏覽器上訪問 URL報404錯誤，如圖11。

　　進一步分析404 Error的原因，鉆取性能索引/IOST/as.do的Error，定位到一個JRedis API的Socket連接失敗，如圖12。

　　效果

　　JRedis為緩存服務器。Web前臺將根據一定規則，從數據庫直接獲取需瀏覽或查詢的信息進行顯示，為了規避當前 系統請求負擔引發事務處理失敗的情形，引入Redis緩存服務器，使系統請求入口點統一從緩存進行處理，以達到快速訪問和確保事務成功的雙重目的。引入緩 存服務器大幅度地提高了系統處理客戶請求的能力,解決了系統處理網絡I/O操作的瓶頸問題。不但提高系統可擴展性，而且有利于提高系統吞吐率。

　　更多解決方案》》http://www.51testing.cn/

　　dynaTrace工具》》http://www.51testing.cn/product_service/dynatrace.html

版權聲明：本文為51Testing軟件測試網原創，未經明確的書面許可，任何人或單位不得對本網站內容復制、轉載或進行鏡像。51testing軟件測試網歡迎與業內同行進行有益的合作和交流，如果有任何有關內容方面的合作事宜，請聯系我們。