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

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

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

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

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

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

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

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

缓存里面到底放些什么也不得而知，设置一兆，系统会加倍变成两兆，但实际缓存却只能缓存一百多K的数据（测试方法为先创建socket,然后sleep等待。启动发送程序发送包，发送完大概8兆数据后退出，接收程序又过了几秒才结束sleep，开始从缓存中读数据，只能读出一百多K，缓存设置为很大就可以一个包不丢的读出，证明丢包确实是因为缓存大小不够）

从这个测试结果来看把程序改为先接受数据，再放入队列，对性能的提升应该都有帮组（不管是从thoughput还是latency都有帮助）。程序处理一条消息大概需要10个微妙，把接收这两三多微秒移到另一个线程，理论计算大概能提升20%左右。