【性能測試】常見的性能問題分析思路（一）道與術

微信搜索【大奇測試開】，關注這個堅持分享測試開發干貨的家伙。

本次是一篇關於性能測試的，從行業的背景來看，測試開發（包括但不限於平台工具開發、自動化..）和性能測試一直是持續關注最高的，這里暫不討論新新方向比如音視頻、大數據、AI等，畢竟筆者也沒過多經驗，很多人可能跟我經歷很類似，因為不是專門做性能測試，大部分都是利用一些開源工具進行業務是否滿足需求上的測試，很少能做或者沒經歷進步一步的性能分析，以下是組內性測試小組，專注性能測試比較資深伙伴，我們稱呼為 “禧子哥” 的一次分享內容，對比好多文章和一些外部分享，個人覺得真的是干貨，因此特別爭得同意，大奇再此基礎上進行部分整理和優化，呈現給大家，最后再次感謝原作者 “禧子” 的干貨總結和無私分享。

 

壓測目標

性能測試一定是要有它的目的或目標，一切拍腦袋不知道想要干啥的性能測試需要真的是只能用呵呵來形容，分享者基於目前給出，壓測有三大目標：

1.  找出性能的瓶頸
2. 給出基准指標
3. 機器配置容量規划

性能缺陷類型

對於性能問題產生的類型，大體總結為五類，通過一個思維導圖展示

性能分析方式方法

任何性能問題出現首先都會有對應現象發生，現象分為前台現象和后台現象，這里我們講的是前台現象，也就是用戶或測試者感受到的表象，如TPS曲線波動，響應時間持續上漲等。有些性能問題，前台表現很正常，用戶可以正常使用，但是后台可能發現一些異常現象，例如cpu比較高，可用內存比較少等，這種情況下，不要輕易做任何性能調整，否則可能引發其它性能問題，只要前台使用正常滿足業務容量目標即可。
現象可以大致分為3大類

1. 單個功能點慢

java進程還在，系統首頁、登錄均正常，只是訪問到特定功能點，特定接口時比較慢，且現象每次操作都可以重現。

2. 系統慢

java進程還在，系統打開首頁、登錄操作很慢，或者一直停在那里。即使登錄到系統中后，點所有菜單、功能都很慢，整個系統基本無法使用。相當於我們的整條單鏈路或全鏈路都受影響

 

3.宕機

java進程自動中止，進程消失。

這3種現象不是孤立存在的，關系如下：

1. 單個功能點慢，一旦積累到一定程度，應用服務器很多線程都在處理此功能時，會導致系統變慢，甚至可能導致宕機。

2. 系統變慢，基本上都是由於用戶用操作了某個功能，此功能存在死循環或者資源不釋放之類的代碼問題，例如發生內存溢出，導致系統變慢。在系統慢的情況下，找出有問題的單個功能點是關鍵。

3. 宕機，通常也是由於某個功能點的性能問題導致。

4. 只要知道哪個功能點或操作慢，就可以進行優化。多數情況下，我們不知道是什么操作導致的性能問題，分析診斷的主要目的就是找出這些功能和操作。

 

單點慢如何處理    

如果我們已經知道某個功能點慢，並且可以重現，那么問題就比較容易解決了，檢查代碼、優化sql語句等。多數情況下，單個功能點慢的問題是sql語句執行的慢，抓出執行效率低的sql語句，可以進一步定位問題。對於oracle數據庫，可以通過“Plsqldev-工具-會話” 這個工具進行抓取,或者生成AWR報告，對於mysql數據庫可以借助explain等解析語句分析。
執行效率低的sql語句查看執行計划，是否走全表掃描，索引創建是否合理，檢查基礎數據分布是否合理等。

若是B/S的，可以通過httpwatch，fiddler查看哪個點比較慢。

宕機如何處理

根據宕機的解釋，多數情況下我們遇到的性能問題並不屬於“宕機”，只是我們習慣這么叫而已。一旦出現宕機，唯一可以做的只能是查看宕機日志。根據目前項目經驗，所有宕機問題都是由於內存溢出導致（內存溢出並不一定引起宕機），所以如果出現宕機，應該首先檢查jvm內存參數是否設置、設置的是否正確，如果確認jvm內存參數沒有問題，需要進一步分析宕機日志文件，如heapdump/coredump文件，javacore文件等。

 

系統慢如何處理

絕大多數的性能問題都是“系統慢”的問題。系統慢，可能慢在應用服務器端、數據庫端、網絡端、客戶端(客戶端慢通常比較容易定位)，可以先從以下四個方法進行分析診斷，定位大的方向：

1. 觀察服務器資源利用率

主要觀察應用服務器、數據庫服務器的cpu、內存使用情況，如果應用服務器cpu利用率較高，例如在50%以上，則說明應用服務器正在處理請求，有壓力。如果數據庫服務器cpu利用率較高，例如在50%以上，則說明數據庫服務器正在處理請求，有壓力，可能有較耗時的sql語句在執行。資源分析屬於輔助分析，需要結合其它方法一起使用。

2. 查看日志

查看日志非常重要，日志里會提供非常有用的線索，需要養成查看日志的習慣。查看日志定位問題需要一定的經驗和積累，以下是查看日志的幾條經驗和建議（查找日志中是否有如下關鍵字信息）：

• Outofmemory：有內存溢出，通常會生成heapdump文件，需要結合javacore進一步分析，可以借助相關工具。

• can not open connection：應用服務器的數據庫連接池用光，檢查連接參數是否設置正確，如果參數配置沒有問題，需要結合javacore進一步分析

• Stack overflow：結合javacore進一步分析

• Dead lock：日志中會明確指明哪段代碼發生了死鎖 

3.關注時間戳分析日志時關注時間戳信息，尤其關注系統變慢前后時間點的日志。關注反復出現的日志信息，關注同一時間點大量出現的日志信息出現了很多很多錯誤信息，對這些信息尤其需要重點關注。
4.其它顯而易見的錯誤如網絡連接錯誤等，可以檢查當前正在處理什么請求，可以查看jvm內存的使用情況，檢查線程、數據庫連接、控制台檢查只是輔助，需要結合其它措施，如利用全鏈路系統一起分析。比如：生成java線程快照，常用命令

• kill -3 進程號或者jstack 進程號

• Jstack –l  進程號

• jstat –gcutil 進程號 關注內存堆使用情況

最后總結下系統慢的三個大方向

1. 應用服務器端問題，首先檢查jvm參數、連接參數是否設置正確，參數沒有問題那就是代碼問題，根據日志、javacore、heapdump的分析結果，檢查、修改代碼。

2. 數據庫端問題，通常都是由於低效的sql語句導致，優化sql語句即可，也可能是數據庫連接池。

3. 其它調用過程問題，例如網絡連接問題（日志中會有錯誤信息），檢查網絡聯通穩定性等。

通用性能分析思路

基於上面的性能分析方法內容，總結下性能分析的通用方法，同樣給出一個自上而下的思維圖，從現象出發，分析初步范圍，根據脈路進一步縮小范圍，進行不斷的驗證測試等，從而定位問題，解決問題。

 

 

本篇就分享這些，下一篇將基於此文分享下實際案例和一種工具使用技巧。

堅持原創，堅持實踐，堅持干貨，如果你覺得有用，請點擊推薦，也歡迎關注我博客園和微信公眾號。