linux多线程socket编程一些心得

http://hi.baidu.com/netpet/blog/item/2cc79216d9012b54f2de32b9.html

 

 前段时间将新的web模型办到linux上来，用epoll代替了IOCP，经测试确实性能提高了很多，吞吐量也寓所提高，对于linux下面的网络编程不是三言两语就能说得透的了，加上多线程就更麻烦了，但是epoll模型的精髓就是事件驱动，这种模型提供了保持连接socket直线增涨而性能不会直线下降的特性，纵观epoll kueuen select等等，所有都是在解决一个socket不需要一个线程的问题，将事件去分开来
    在ningx（有人用他同时保持了3万个处理连接）上的到了一些体会，这些不仅使用于web这样模型的server，同样适合于所有其他的比如游戏、ftp服务器等。
    维持高在线人数的关键问题在于事件处理模型需要m：n,m远做多服务器网络协作程序任何时候记住减少一次路由比优化100次一个算法都划算。
   nginx的做法是将处理程序严格区分开来（本次我作的Flower web server也是基于此原理），等待epoll等事件通知，他在全局范围内维护了两个链表，一个读连表，一个写链表，epoll等系统网络通知通知了某个socket可操作后他便将状态保存在相应的变量里面，然后采取m个线程轮询执行任务，这样线程就不用等待网络io堵塞，正常的一个read socket数据需要循环，直到数据读完或者产生错误，但我的处理不是这样的，我在全局范围内维护一个统一的socket fd表，这是linux的特性决定的，因为linux的socket fd是从很小的值开始的，并且同一时间内不会重复（估计内部有线程锁），所有fd本身就是一个重要的标识量，并且一个大的fd释放后还会从小的开始重复利用，winsows下的就不一样，他是一个长长的指针，所有我的全局状态表就需要一个用fd作为索引的标识就可以了，最大的fd也就是同时保持在线人数的大体数字，我设置了一个20000的状态表，暂用栈内存很小，基本上不会被用完。
     然后我同样对read和write设置两个独立的状态链表，用m个线程来处理，所不同的是这两个表只有一个fd项，其余的数据都是保存在堆分配的全局状态表中，我对全局状态表设置很多的状态值，比如：read write readed writed needRepetRead needrepetWrite restart等等，这样我可以将其他的处理分别用新的状态链表来保持，锁不同的是全局表的状态不一样，从而达到多个处理程序协作的问题，互斥锁只存在于各个处理环节，如果读的环节慢了就可以加大读的线程数，写的慢了可以加大写的，处理的过程慢了可以加大处理的，这样方便系统后期调试优化，但是每一个环节都不会影响全局表的处理，不会因为一个线程堵塞或则死掉导致全局的状态都没法进行

   初步作出来的模型同样采用sendfile ＋epoll情况下，经测试我的server已经略微超过nginx，下面就是进一步的规范和优化扩展的部分了

 

我也是刚刚转到linux下面来，polled,select是早期的两个模型，总的来说这个种都是为了到达到事件通知功能，内部实现原理不一样，所以在实际应用的过程中就可以做这样的分层：事件模型和协议处理模型分开。有很多这样的例子，nginx就是这样的，编译的时候根据不同的系统选择不同的事件通知模型，也就是说你写的程序觉大部分跟这几个函数没关系，他们只是起到检测socket事件的作用，至于内部区别你可以去看源代码，也有网上的大量说明，没必要这里再细细罗列，目前epoll在处理大量用户连接的情况下综合性能最好，少量连接（1－200个）就都差不多了，甚至pool或者select比epoll还好，这是他们实现的机制不同

 

Reference:

epoll为什么这么快 http://www.cppblog.com/converse/archive/2008/10/12/63836.html