設計 三方 性能 行修改 rtsp 基本 自己 actor模型 ima

轉自：http://www.cnblogs.com/lanyuliuyun/p/4483384.html

1、EventLoop

這裏說的EventLoop不是指某一個具體的庫或是框架，而是指一種程序實現結構。這種結構多是基於IO多路轉接的API（select、poll、epoll之類）以reactor模型，實現IO事件處理、timer和異步事件處理。具體常見的庫有libev、libevent，以及陳碩（@bnu_chenshuo）的muduo。這些庫或是框架基本的原理流程都類似，區別都是在API接口功能和多平臺支持之上。這裏就不具體的對此進行展開討論了，接下來說說自己對EventLoop的一點理解，歡迎各路大俠拍磚。

先簡單拋出一個自己的結論：現在的程序服務基本上都可以使用EventLoop的結構來驅動。

其原因是需求都近乎於類似，基本上都要處理IO事件進行消息收發與外部進行通訊、都要實現timer來進行定時、都要發起一些異步處理過程。而這些都可以用EventLoop進行抽象。對這些功能實現了統一的抽象實現之後，在此之上實現基礎的TcpServer、TcpClient、UDP Peer就方便的多了，在往上進一步加上各自的業務邏輯，就形成了各種Server、客戶端。可以說核心的結構都是類似，細分的差別就體現在內存管理、包收發控制（擁塞控制）、並發模型設計、系統架構Scale和健壯容錯能力方面。

如下圖所示

虛線框中既是基本的EventLoop的組件功能了。功能豐富一點庫會在APP Sever/APP Client中實現諸如http server/http request之類的功能了，比如陳碩的muduo，或是精簡一點，TCP Server/TCP Client/UDP Peer都沒做，只實現了IO Event Handle、Timer、Async Event，比如libev。自己分析了muduo實現，模仿其API，也用C杜撰了一套精簡的實現，實現了上述框架的的功能，APP的部分具體實現了RTSP Server/RTSP Request功能，也在公司裏用的挺好，這裏要推薦一下muduo，其API是自己見過功能的庫中使用最方便的一個（也可能是自己孤陋寡聞，沒見過更牛掰的），也促成自己重新造了一個輪子。

2，性能問題問題

自己遇到的性能問題主要是體現在CPU使用率上。在自己最近做的項目中，遇到過三次CPU使用率過高的問題，但問題原因各不相同。這裏記錄一下

1) 一次是因為軟件使用的一個第三方SDK中默認開啟了軟件解碼運算而導致的。發現問題原因所在首先要進行度量，以確定具體是在哪裏耗CPU明顯。此時自己使用的是process explorer工具（windows）中線程查看功能，其可以具體的查看一個進程中各個線程的運行情況，包括CPU使用率和調用棧。對此很直接找到問題的元兇。之後聯系對應廠商開發人員，對SDK進行修改，關閉默認解碼操作，提供開關控制後解決。

2）一次是因為檢測了IO句柄上的無用的write事件，而導致代碼流程空轉所致。經過實際驗證，發現該問題可控，當停止所有的網絡功能之後，CPU使用率立馬回復正常，就基本確定於網絡功能有關。解決該問題仍然是先進行度量，這次的度量工具是VS中的性能分析工具，用其對各個函數的調用情況進行采樣，很輕松的發現那些函數調用的次數比較多，就直接定位到問題點，經過分析後將write事件監測改為按需進行後解決問題。

3）此種情況準確來時是BUG。第三次是因為代碼在一個不常見的處理分支中而陷入了死循環。同樣先進行分析發現該現象不可控，整個程序已經完全不能相應更多的控制操作。遂用VS以調試方式將程序跑起來，將問題復現後，將程序暫停運行後恢復運行，重復幾次之後，發現每次暫停時執行流程都陷入在同一個地方，就基本確定代碼在這個地方陷入死循環了。仔細地分析了代碼，結合實際外部觸發條件後，找到了bug所在。修改代碼重新進行驗證測試，問題解決。

記錄自己對EventLoop和性能問題處理的一點心得【轉】