EasyDarwin开源流媒体服务器性能瓶颈分析及优化方案设计

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