darwin之socket消息处理性能问题研究

windows下darwin接收到socket消息如何处理?
所有的socket消息入口只有一个线程,而且是单线程:void EventThread::Entry().
这个线程不断地遍历所有注册到窗口的socket消息(每一个新的socket,注册到窗口的消息id不同).
此处的单线程循环处理所有客户端的消息,是否能达到高性能,个人感觉不能(上百万客户端,仅仅靠单线程捕获消息) 。
当消息到达后,在EventThread中仅仅是调用了一个耗时极短的函数:ProcessEvent。

在EventContext中,该函数将任务放到taskthread队列中(让线程池去处理消息),后直接返回。


事实上,通过调试发现,EventThread线程获监听的消息绝大多数为:FD_READ | FD_ACCEPT | FD_CLOSE,对于
其他消息如:FD_WRITE的消息是很少去注册,直接发送数据到客户端即可。想想也是,rtsp流媒体服务器,不会主动发消息给客户端,都是
接收到FD_READ消息后,去响应该消息而将数据发送给客户端。FD_WRITE消息很少注册将大大降低EventThread线程的工作压力,
当多个客户端同时从服务器上接收rtsp流时,EventThread线程压力很低,因此此过程中读消息(FD_READ | FD_ACCEPT | FD_CLOSE)
很少发生。 

但是当有多个rtsp推流器,将数据流推送到darwin服务器上时,服务器将频繁的收到FD_READ消息,因此压力会很大。服务器同时支持多少个推送客户端推送rtsp数据流,需要进一步测试。





模拟一个rtsp推流器,推送视频流到darwin服务器上,相当于一个客户端一直往服务器上发送窗口消息(消息id相同),如下所示,服务器会一直收到窗口消息id为1036的socket数据流。








评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sunxiaopengsun

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值