app性能測試診斷與優化--通過現象猜本質

APP性能測試診斷與優化--通過現象猜本質

這段時間忙著幫北京某城商行做移動端性能測試，因移動端IPD、手機等都是無線設備，而且該客戶是面臨全國各地用戶提供移動端APP支持，為了更真實的模擬測試，我跟該項目的項目經理溝通直接在廈門本地通過無線網借用LR工具模擬並發壓力測試。很感謝移動架構組的技術專家肖工的幫忙，讓我順利的在本地搭建了模擬機，並跟該項目經理要了生產環境的APK工程包部署後，並根據項目組提供的業務操作手冊學習業務知識，後使用LR開發腳本進行壓力測試。
因地域距離關系，而且是直接在生產環境壓力測試，生產環境在北京，壓力測試機器在廈門，通過無線壓測，所以測試過程對服務器資源使用監控成為一大問題，只能在每次壓力測試時通過微信交流，在碰到響應時間等相對比較長或者TPS不穩定時，讓項目經理協助監控，拍照截圖我分析，還好自己這十幾年到出差支持項目做性能故障分析優化，對各類問題通過LR前端能猜測出後端是數據庫問題還是應用問題，雖然沒辦法做到真正的知微見著，但是還能通過現象了解本質問題，並提供優化建議，這主要是因為工作走心，也有事物去總結積累的效果。

剛開始壓測時因是默認部署後默認配置等問題導致響應時間偏高，TPS低，經項目經理反饋應用CPU 都82%以上如下圖：


測試了四五支交易發現都有共性問題，響應時間都是六秒以上，手機端響應時間一般是258原則，超過5秒使用者都會煩躁直接關閉，一般建議都是3秒以下，因此指標沒辦法滿足。
猜測應該是應用服務器配置不合理導致的，因為登錄退出、頁面連接等也有共性問題，大概測算下後，給項目經理提供相關的配置優化意見後，竟然真的解決了，主要是tomcat相對好優化，然後通過再壓測響應時間都在1秒以下。


一般銀行的APP移動端的應用邏輯也不會太復雜，代碼寫法問題相對比較少，而且是胖客戶端的，數據傳輸雖單機業務數據量少，但是並發大，在測試過程中如果發現性能問題，一般是網絡帶寬問題或者後端處理邏輯問題。假如測試過程中如果大部分交易有問題一般是軟硬環境配置不合理居多，如果有時偶爾一兩支查詢交易響應比較慢，一般是SQL寫法問題引起的，建議先看SQL語法執行路徑如何，是走全表掃描，全索引掃描？是否因多表關聯等寫法導致的，這時在根據實際業務情況進行優化。--當然問題原因很多還是多監控診斷分析，性能監控數據說話才更真實和權威。

本文出自 “泊涯” 博客，請務必保留此出處http://372550.blog.51cto.com/362550/1955201

APP性能測試診斷與優化--通過現象猜本質