性能工具設計簡介

　　客戶端的性能是用戶體驗的一個非常重要的方面。在需求設計時要考慮到可能的性能問題;在不斷的迭代開發新功能的同時要保持性能的穩定;在運營過程中要能追蹤并解決歷史遺留的性能問題。工欲善其事，必先利其器。雖然有不少現成工具可以使用，但自己設計性能工具更靈活，更有針對性。性能工具的主要功能是監控目標程序獲取相關數據，組織數據并對其加以分析，幫助我們定位問題、找出性能瓶頸。

　　需要哪些數據

　　常見的性能問題主要有：界面卡、反應慢、CPU高、內存大等幾個方面。我們針對這些情況來考慮需要收集哪些數據，以及如何來記錄這些數據(針對windows客戶端)。

　　1、界面卡、反應慢

　　界面卡、反應慢主要是指程序的響應速度過慢，包括：界面對鼠標鍵盤輸入的響應速度;一些比較耗時的系統API的處理速度，比如讀寫文件等;以及目標程序的一些關鍵路徑的執行速度。

　　界面響應速度，這里我們可以用每次消息循環的執行的時間點以及時間消耗來判斷。對于大多數windows程序來說hook GetMessage并記錄下來每次調用GetMessage的時間點就可以了。但也有些客戶端自己實現的消息循環，這里我們就需要hook對應的函數(比如PeekMessage)或是在消息循環里加上log。另外我們也可以向目標程序發送WM_NULL消息跟據其響應時間來判斷響應速度。在這里，我推薦以兩次消息循環的時間間隔或是對WM_NULL消息的響應速度小于50ms做為一個判斷標準，大于這個值則認為“卡”。

　　系統API執行速度，用hook的方法記錄調用的線程ID、時間點、消耗時間以及一些必要的參數(比如讀寫的是哪個文件)。通常需要關注的系統API有：CreateFile、ReadFile、WriteFile、BitBlt和StrenchBlt等等。

　　對于一些關鍵路徑，我們需要記錄下來執行時的線程ID、時間點和時間消耗。這一點針對性比較強，直接在目標程序加入log就可以了。當然也可以用hook 的方法，但不推薦。因為Hook的實現相對比較復雜，需要實現一個跳板函數，在跳板函數中記錄相關信息。Hook更適應于記錄一些調用次數頻繁的系統級 API。而一些關鍵路徑往往與目標程序邏輯密切相關，整個過程只有幾次調用，甚至可能只有一次或完全不調用。這樣就完全沒有必要用hook的方法。

　　系統API和關鍵路徑(函數)的耗時，推薦記錄開始時間和結束時間兩個數據。這樣在有嵌套的情況下，比單純記錄消耗時長，更直觀，更便于分析問題。

　　怎么hook?這里推薦參考微軟的detours庫。detours2.1版本之前是開源的。其基本原理是這樣的：1. 把目標函數的前幾行指令拷貝到一個地方，然后在原來的位置替換成一條跳轉指令。2. 通過跳轉指令跳轉到自己實現的跳板函數，在跳板函數就可加入自己的代碼了。如下：

　　2、CPU高、內存大

　　針對CPU高、內存大，我們按時間順序以固定的時間間隔記錄下來目標進程的CPU和內存的消耗就可以了。在CPU占用方面我們也可以更進一步記錄下每個線程的CPU消耗

　　3、有了上面的數據就夠了嗎?

　　不夠。比如，當我們收集到一組數據，分析后發現目標進程在啟動后35秒-40秒的這段時間對WM_NULL消息無響應(界面卡住)。然后呢?然后我們仍然沒有辦法知道為什么會卡，以及卡在哪里。所以我們還需要目標的調用堆棧。同樣按時間順序以固定的時間間隔記錄下堆棧信息。這樣當我們發現問題的時間點后，便能得到當時一個堆棧執行情況。接下來就可以通過review代碼來解決問題。

　　至于獲取調用堆棧。微軟提供的 StackWalk64 就可以了，具體請查閱MSDN。當然如果你喜歡自己通過堆來還原調用堆棧，那么可以使用NtQueryInformationThread在取得線程信息后，根據ebp esp來回溯吧。

　　4、還需要哪些數據?

　　任何你關注的數據都可以記錄下來。假如你關注IO對性能的影響，那么就記錄下IO量和頁面錯誤的數據;你懷疑是不是有其它模塊的注入影響了你的程序，那么你也可以記錄下來目標進程的模塊信息……

　　組織分析數據

　　把數據初步整理，以圖形的方式直觀的表現出來。下面舉幾個例子。

　　用樹表示關鍵函數的執行所花的時間。

原文轉自：http://www.uml.org.cn/Test/201302212.asp