socket接收数据的速度测试结果

在处理多播数据时发现丢包问题,分析认为是程序处理速度不足导致。通过测试,发送30万个包约耗时60万微秒。阻塞式接收与发送速度相当,而使用select方法则慢一倍。测试表明,缓存大小与丢包率不成正比,增大缓存并未显著减少丢包。考虑通过接收线程异步处理,将接收时间移出主线程,预期能提升约20%的性能。
摘要由CSDN通过智能技术生成

最近工作上遇到一个问题,接收多播数据时经常出现丢包。网络情况良好,所以丢包实际是因为程序处理速度不够而导致的,当然,这种情况可以通过简单的增加socket的缓存大小来搞定。设置成一百多兆肯定不会丢(当然,要设这么大必须先改系统设置允许才行)

 

不过这没有解决程序处理速度不够快的问题,当时实现的时候把接收包和处理包都放在同一个线程里面。要解决这个丢包问题,除了增加缓存大小,也可以每次一接收到包就把包放入一个队列,除了可以解决丢包问题之外,还可以小小的增加一点点并发。

至于到底能增加多少,做了几个简单的测试。

首先是写了一个发包程序,一次性发送三十多万个包。每个包都很小,几十个字节左右,使用127.0.0.1和真实的网络接口,对发送速度影响不大,在我测试的机器上,差不多要60万微秒左右

 

如果采用阻塞式的接收方法,就是一个recvfrom()堵在那里,来一条接收一条。接收速度基本和发送速度相等。

 

而如果采用select的方法,先检测是否有数据可读,可读再调用接收方法去接收,这样要慢一些,大概要慢上一倍,当然这个好理解,select要多做很多事,何况我还使用了一个叫Poco的三方包,要先把需要检测的socket放入一个vector。然后才调用一个封装过的select,把有可读标志的socket再放入另一个vector。慢这么多也就可以理解了。

另外观察到的一个现象就是缓存大小和丢包比率完全不成正比,在使用select方法的时候,当缓存大小设为一兆时,丢包差不多一半。而增加到8兆之后,丢包仍然有数万个。具体原因以后心情好再来

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值