linux多线程socket编程一些心得

时间:2023-12-12 14:44:26

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远<n, m为socket,n为连接socket,不管你有多少个cpu(比如2cpu 4核),计算机能同时处理的线程数都是很少的,socket的关键在于网络等IO的延迟,如果让线程堵塞在一个网络IO上那所有的基础优化算法都是白搭,因为算法的不佳只能影想很短的时间,但是网络IO延迟就很难讲了,有位前辈说了很好的一句话:做多服务器网络协作程序任何时候记住减少一次路由比优化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