堅持原創，堅持實踐，堅持乾貨，如果你覺得有用，請點擊推薦，也歡迎關注我部落格園和微信公眾號。
【性能測試】常見的性能問題分析思路（一）道與術
微信搜索【大奇測試開】，關注這個堅持分享測試開發乾貨的傢伙。
本次是一篇關於性能測試的，從行業的背景來看，測試開發（包括但不限於平台工具開發、自動化..）和性能測試一直是持續關注最高的，這裡暫不討論新新方向比如音影片、大數據、AI等，畢竟筆者也沒過多經驗，很多人可能跟我經歷很類似，因為不是專門做性能測試，大部分都是利用一些開源工具進行業務是否滿足需求上的測試，很少能做或者沒經歷進步一步的性能分析，以下是組內性測試小組，專註性能測試比較資深夥伴，我們稱呼為 「禧子哥」 的一次分享內容，對比好多文章和一些外部分享，個人覺得真的是乾貨，因此特別爭得同意，大奇再此基礎上進行部分整理和優化，呈現給大家，最後再次感謝原作者 「禧子」 的乾貨總結和無私分享。
壓測目標
性能測試一定是要有它的目的或目標，一切拍腦袋不知道想要幹啥的性能測試需要真的是只能用呵呵來形容，分享者基於目前給出，壓測有三大目標：
- 找出性能的瓶頸
- 給出基準指標
- 機器配置容量規劃
性能缺陷類型
對於性能問題產生的類型，大體總結為五類，通過一個思維導圖展示
性能分析方式方法
任何性能問題出現首先都會有對應現象發生，現象分為前台現象和後台現象，這裡我們講的是前台現象，也就是用戶或測試者感受到的表象，如TPS曲線波動，響應時間持續上漲等。有些性能問題，前台表現很正常，用戶可以正常使用，但是後台可能發現一些異常現象，例如cpu比較高，可用記憶體比較少等，這種情況下，不要輕易做任何性能調整，否則可能引發其它性能問題，只要前台使用正常滿足業務容量目標即可。
現象可以大致分為3大類
1. 單個功能點慢
java進程還在，系統首頁、登錄均正常，只是訪問到特定功能點，特定介面時比較慢，且現象每次操作都可以重現。
2. 系統慢
java進程還在，系統打開首頁、登錄操作很慢，或者一直停在那裡。即使登錄到系統中後，點所有菜單、功能都很慢，整個系統基本無法使用。相當於我們的整條單鏈路或全鏈路都受影響
3.宕機
java進程自動中止，進程消失。
這3種現象不是孤立存在的，關係如下：
-
單個功能點慢，一旦積累到一定程度，應用伺服器很多執行緒都在處理此功能時，會導致系統變慢，甚至可能導致宕機。
-
系統變慢，基本上都是由於用戶用操作了某個功能，此功能存在死循環或者資源不釋放之類的程式碼問題，例如發生記憶體溢出，導致系統變慢。在系統慢的情況下，找出有問題的單個功能點是關鍵。
-
宕機，通常也是由於某個功能點的性能問題導致。
-
只要知道哪個功能點或操作慢，就可以進行優化。多數情況下，我們不知道是什麼操作導致的性能問題，分析診斷的主要目的就是找出這些功能和操作。
單點慢如何處理
如果我們已經知道某個功能點慢，並且可以重現，那麼問題就比較容易解決了，檢查程式碼、優化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 進程號 關注記憶體堆使用情況
最後總結下系統慢的三個大方向
-
應用伺服器端問題，首先檢查jvm參數、連接參數是否設置正確，參數沒有問題那就是程式碼問題，根據日誌、javacore、heapdump的分析結果，檢查、修改程式碼。
-
資料庫端問題，通常都是由於低效的sql語句導致，優化sql語句即可，也可能是資料庫連接池。
-
其它調用過程問題，例如網路連接問題（日誌中會有錯誤資訊），檢查網路聯通穩定性等。
通用性能分析思路
基於上面的性能分析方法內容，總結下性能分析的通用方法，同樣給出一個自上而下的思維圖，從現象出發，分析初步範圍，根據脈路進一步縮小範圍，進行不斷的驗證測試等，從而定位問題，解決問題。
本篇就分享這些，下一篇將基於此文分享下實際案例和一種工具使用技巧。
