EasyDarwin現有架構介紹

EasyDarwin的現有架構對網絡事件的處理是這樣的，每一個Socket連接在EasyDarwin內部的對應存在形式就是一個Session，不論是RTSP服務對應的RTSPSession，還是HTTP服務對應的HTTPSession，都是一個繼承自Task類的具體應用層對象；

EasyDarwin有一個專門的網絡事件處理的線程：EventThread（網絡事件線程），EventThread一方面采用select（Windows）或者epoll（Linux）的網絡IO模型，將檢測到的socket網絡事件以Task（就是上層實際進行業務處理的Session）任務的形式投遞到線程池中線程的任務隊列TaskQueue中，另一方面EventThread維護Socket描述與Session::Task對象建立的key/value哈希表HashTable；

當socket第一次連接的時候，會先進行Session的建立，再Register到Hash表中，后面再次與socket相關的網絡事件，都會直接在Hash表中獲取到socket對應的Session進行網絡事件的具體處理；

線程池中的線程不斷循環讀取本線程維護的任務隊列TaskQueue中的Task，取出Task后，進行Task::Run（）執行，而具體的執行過程就是在繼承自Task的Session中Run（）執行，那么在Session::Run（）中執行的就是具體的Socket報文讀取與處理，處理完成后響應，而對一個socket一次網絡報文從讀取、解析、處理、到回復響應的整個流程都是線程阻塞的，也就是在這個過程中，整個線程只能處理流媒體服務器跟一個終端的交互；

瓶頸分析

網絡事件線程EventThread的主要工作就是通知，通知BlockingTaskThread有網絡消息來了，需要讀取和處理，然后BlockingTaskThread就開始處理具體的網絡事件了，從整個讀取、解析、到處理、響應，必須完整執行完成之后，當前這個BlockingTaskThread才可能會執行下一個Socket的網絡事件，以通用的服務器來算，8核的服務器，我們的線程池建立16個線程，8個BlockingTaskThread（網絡消息處理線程），8個ShortTaskThread（內部任務處理線程），一旦網絡并發數劇增，那么在同一時刻，最多也就只能讀取8個客戶端發來的請求，如果服務器設計的鎖比較少、處理的阻塞點控制的比較好，并發處理上還能夠過得去，就像當前EasyDarwin的架構一樣，處理小規模的并發上比較具有優勢，但想再提升一個級別，例如萬兆網卡上，在CPU還有富余的情況下首先跑滿帶寬這個需求，還需要進一步的優化；

優化方案設計

近期也一直在跟EasyDarwin開源團隊成員Fantasy在探討這個問題，得出的行業比較通用的做法，我們將改造EventThread，在EventThread中就將客戶端請求的一個一個完整的RTSP/HTTP請求，讀取出來，再以MsgTask的形式，攜帶完整的數據包+對應的Session指針引用，投遞到TaskThread中，而這個時候TaskThread也不區分BlockingTaskThread和ShortTaskThread了，統一都為TaskThread，TaskThread內部循環讀取TaskThread::TaskQueue中的Task進行處理，獲取到MsgTask后，解析Msg，處理，再調用MsgTask中的Session進行Response的發送，這樣就能非常均勻地將網絡報文先讀取到系統，再通過內部的線程池進行報文處理的消化，和響應的發送，充分地利用的線程池和消息隊列，大大增加了網絡的吞吐量；

獲取更多信息

Github：https://github.com/easydarwin

郵件：support@easydarwin.org

WEB：www.EasyDarwin.org

Copyright ? EasyDarwin.org 2012-2016

轉載于:https://www.cnblogs.com/babosa/p/5904631.html

總結

以上是生活随笔為你收集整理的EasyDarwin开源流媒体服务器性能瓶颈分析及优化方案设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。