微信搜尋【大奇測試開】，關注這個堅持分享測試開發乾貨的傢伙。
本次是一篇關於效能測試的，從行業的背景來看，測試開發（包括但不限於平臺工具開發、自動化..）和效能測試一直是持續關注最高的，這裡暫不討論新新方向比如音視訊、大資料、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語句即可，也可能是資料庫連線池。
-
其它呼叫過程問題，例如網路連線問題（日誌中會有錯誤資訊），檢查網路聯通穩定性等。
通用效能分析思路
基於上面的效能分析方法內容，總結下效能分析的通用方法，同樣給出一個自上而下的思維圖，從現象出發，分析初步範圍，根據脈路進一步縮小範圍，進行不斷的驗證測試等，從而定位問題，解決問題。
本篇就分享這些，下一篇將基於此文分享下實際案例和一種工具使用技巧。
堅持原創，堅持實踐，堅持乾貨，如果你覺得有用，請點選推薦，也歡迎關注我部落格園和微信公眾號。