C++ 背景程式即時效能監控

面對的問題：

做背景程式經常會被問一句話，你的程式能撐多少人。一般官方一點的回答是這個得根據實際情況而定。實際上背景程式的效能是可以被量化的。我們開發的每一個伺服器程式，對效能都非常有底，以為我們有資料。So，能撐多少人不少隨便猜的，讓資料報表來說話。

另外一種情況經常發生在開發人員之中，甲乙丙一起討論介面實現，經常會說這麼實現效率太低，那麼實現效率才高等。實際上，效率高低都是相對而言的。一個函數1ms執行完畢夠快嗎？看起來挺快，若某介面需要此函數100次迴圈，那麼情況就不是很樂觀了。但是若此介面又是十天半個月才會被觸發一次，似乎事情又變的不是很嚴重。說到這裡想起《unix編程藝術》上關於效能最佳化的總結：

• 最有效最佳化往往是最佳化之外的，如清晰乾淨的設計
• 最有效最佳化就是不最佳化，摩爾定律會為你最佳化
• 如果確定要最佳化，必須找到真正的瓶頸

還有一種跟效能有關的情況是，背景程式經常有很多組件組成。比如在運行期發生介面調用效能下降的情況，必須知道是那些組件效能下降引起的。如果可以即時的知道所有介面的效能資料，以上的問題都可迎刃而解。

總結如下原因，必須開啟即時效能監控：

• 我們需要知道系統的輸送量，以此參數做部署等。
• 即時瞭解各個系統組件的效能，某組件發生故障，可以及時發現
• 獲得程式介面調用熱點，調用多且慢的介面才需要最佳化

解決方案：

背景程式開發一個專門統計效能的組件，其需要有如下功能：

• 可以匯總效能資料，如定時將1小時內說有介面調用開銷、次數等資料匯總到檔案
• 可以非常方便的與邏輯層介面整合，比如在現有介面增加一行代碼即可
• 直觀的報表，效能資料寫入檔案必須按照通用的格式，方便工具分析資料，產生報表

效能監控組件

我實現了一個效能組件performance_daemon_t。介面如下：

//! 效能監控class performance_daemon_t{public:    struct perf_tool_t    {        perf_tool_t(const char* mod_):            mod(mod_)        {            gettimeofday(&tm, NULL);        }        ~perf_tool_t()        {            struct timeval now;            gettimeofday(&now, NULL);            long cost = (now.tv_sec - tm.tv_sec)*1000000 + (now.tv_usec - tm.tv_usec);            singleton_t<performance_daemon_t>::instance().post(mod, cost);        }        const char*    mod;        struct timeval tm;    };public:    performance_daemon_t();    ~performance_daemon_t();    //! 啟動線程，建立檔案    int start(const string& path_, int seconds_);    //! 關閉線程    int stop();    //! 增加效能監控資料    void post(const string& mod_, long us);

perf_tool_t 是工具類，構造和析構自動調用兩次gettimeofday擷取函數調用開銷，例外有輔助宏定義如下：

#define AUTO_PERF() performance_daemon_t::perf_tool_t __tmp__(__FUNCTION__)#define PERF(m)     performance_daemon_t::perf_tool_t __tmp__(m)

使用樣本:

void foo(){    AUTO_PERF();    //! TODO -----}int main(int argc, char* argv[]){        singleton_t<performance_daemon_t>::instance().start("perf.txt", 5);     foo();}

performance_daemon_t 每隔5秒將效能統計資料輸出到perf.txt， perf.txt的內容是CVS檔案格式。

報表工具：

perf.txt 檔案內容還不夠直觀，樣本內容如下：

time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times20120606-17:01:41,dumy,515,174,254,3937,39020120606-17:01:41,foo,5924,4,506,1976,103020120606-17:01:41,test,304,8,243,4115,185time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times20120606-17:11:41,dumy,1086,222,280,5571,31220120606-17:11:41,foo,5707,194,503,1988,77020120606-17:11:41,test,807,8,265,3773,142time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times20120606-17:21:41,dumy,1086,222,680,2571,51220120606-17:21:41,foo,5707,194,403,1388,47020120606-17:21:41,test,807,8,265,4773,442

為產生足夠友好、直觀的報表，我實現了一個WEB報表頁面，http://ffown.sinaapp.com/perf/， 將perf.txt 內容直接粘貼到web 頁面，點擊轉換輸出如下報表：

各個介面效能監控-折線圖：

此圖顯示了三個介面隨時間順序的走勢，可以非常清楚foo、test、dumy三個介面那個時間效能高，哪個時間效能低，一目瞭然。

介面熱點分布圖：

顯示三個介面隨時間調用次數走勢，可以很清楚顯示哪個時間段是高峰期。大餅圖顯示了哪個介面是熱點介面，很明顯，foo 介面調用次數最多，最佳化當優先最佳化foo。

組件實現淺析：

post 介面：

程式把介面調用開銷投遞到效能組件任務隊列中，保證了對介面效能影響最小。

timer定時回調：

timer_service_t 是我用epoll 實現的定時器，主要實現如下:

void timer_service_t::run(){    struct epoll_event ev_set[64];    //! interupt();    struct timeval tv;    do    {        ::epoll_wait(m_efd, ev_set, 64, m_min_timeout);        if (false == m_runing)//! cancel        {            break;        }        gettimeofday(&tv, NULL);        long cur_ms = tv.tv_sec*1000 + tv.tv_usec / 1000;        process_timer_callback(cur_ms);            }while (true) ;}

process_timer_callback 中檢測鏈表內所有的定時任務，若逾時，觸發回呼函數。

備忘：

有人可能當心AUTO_PERF(); 會影響介面效能，其實其平均開銷大約為1us 

代碼實現：

https://ffown.googlecode.com/svn/trunk/example/ff_performance

WEB 報表產生工具：

http://ffown.sinaapp.com/perf/

 文檔：

http://ffown.sinaapp.com/perf/perf.pdf