性能缺陷分析及定位方法
阿新 • • 發佈：2018-06-13
AC 銀行 最大 重啟 後端 控制 響應時間 公眾號 網卡
性能測試缺陷
一般有以下兩種情況：
- 不能滿足既定的性能指標，如：響應時間、資源耗用等；
- 並發錯誤、死鎖、內存泄漏
性能缺陷分類
資源忙不來
資源怠工
性能缺陷分析
從下到上剝洋蔥的方法，逆向請求分析。
從硬件——操作系統——數據庫——中間件——後端應用程序——前端應用程序
實例1
銀行應用系統：linux服務器，語言：java，應用服務器：weblogic，數據庫：oracle，為了加強安全和穩定增加了流量控制功能（當請求量突然大量爆發，流量控制最大的並發流量，攔截其他流量）。
測試策略：
- 基本測試。1個用戶循環壓測5分鐘（獲得系統在無壓力下的基準信息如：響應時間，為後續拐點做對比）
- 負載測試。10個並發用戶單交易的並發測試，驗證是否會有並發錯誤，如：應用鎖、數據庫鎖等
- 容量測試。多個交易按照一定的比例去配比，在按一定的梯度逐步施壓，一直到性能測試結果的拐點，如：響應時間邊長、資源占用很大等。
- 穩定性測試。一定的壓力長時間運行，是否存在內存泄漏、數據庫是否存在問題、變慢等。‘
執行結果：
容量測試：第一梯度10個用戶，響應時間：100ms；第二梯度20個用戶，性能缺陷：響應時間出現線性增長為150~200ms。
bug定位步驟：
- 網絡是否有延遲；ping，查看網卡流量（結果：正常）
- 操作系統：應用服務器、數據庫服務器資源耗用：cpu10%，內存也小，（結果：正常）
- 網絡I/O、磁盤I/O：很小（結果：正常）
bug定位結果：
所以問題確定為：系統怠工。證明應用有什麽地方有排隊現象，類似的現象：高速收費處堵車，但收費處之後的路況卻很好，幾乎沒有車。
bug定位原因：
排隊現象可能存在於：
- 網絡：請求很多，網絡連接達不到；
- 應用服務器：高並發多線程會導致死鎖戶線程鎖；
- 數據庫：多個請求也會產生死鎖現象。
bug原因定位：
- 數據庫是否鎖：oracle有aw2報告分析oracle運行現狀，是否有等待現象。結果：正常
- weblogic：控制臺和應用日誌是否有deadlock、lock、wait現象。結果：正常
- 前端：查看連接數是否正常，connection數量是否正常，結果：發現connection數量特別少，實際請求可能過萬了，確認問題存在於前端請求阻塞。應該是觸發了留空了。但實際上留空是關掉的，可是現象卻實際表明是留空觸發了，結果：重啟應用服務器和數據庫服務器後，問題消失了，大約是留空文件寫完後，未重啟兩個服務器導致留空文件未生效吧，真是醉了【眼睛看到的，未必是真實的 哈哈】
《參考：光榮之路公眾號》
性能缺陷分析及定位方法