前段时间将新的web模型办到linux上来，用epoll代替了IOCP，经测试确实性能提高了很多，吞吐量也寓所提高，对于linux下面的网络编程不是三言两语就能说得透的了，加上多线程就更麻烦了，但是epoll模型的精髓就是事件驱动，这种模型提供了保持连接socket直线增涨而性能不会直线下降的特性，纵观epoll kueuen select等等，所有都是在解决一个socket不需要一个线程的问题，将事件去分开来。
在ningx（有人用他同时保持了3万个处理连接）上的到了一些体会，这些不仅使用于web这样模型的server，同样适合于所有其他的比如游戏、ftp服务器等。
维持高在线人数的关键问题在于事件处理模型需要m：n,m远
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，下面就是进一步的规范和优化扩展的部分了。
haimeishan 于 2013-12-21 10:19:06发表:
非常好