nginx采用epoll的事件模型，为何效率高

http://blog.csdn.net/arieshyde/article/details/6718823

以前就知道在linux下nginx采用epoll事件模型，处理效率高。但是一直不知道具体为什么，今天查看了下文档，了解了原因。

首先nginx支持一下这些事件模型（才考nginx的wiki）

Nginx支持如下处理连接的方法（I/O复用方法），这些方法可以通过use指令指定。

select-标准方法。如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数--with-select_module和--without-select_module来启用或禁用这个模块。

poll-标准方法。如果当前平台没有更有效的方法，它是编译时默认的方法。你可以使用配置参数--with-poll_module和--without-poll_module来启用或禁用这个模块。

kqueue-高效的方法，使用于FreeBSD4.1+,OpenBSD2.9+,NetBSD2.0和MacOSX.使用双处理器的MacOSX系统使用kqueue可能会造成内核崩溃。

epoll-高效的方法，使用于Linux内核2.6版本及以后的系统。在某些发行版本中，如SuSE8.2,有让2.4版本的内核支持epoll的补丁。

rtsig-可执行的实时信号，使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况对于高负载的服务器来说是低效的；所以有必要通过调节内核参数/proc/sys/kernel/rtsig-max来增加队列的大小。可是从Linux内核版本2.6.6-mm2开始，这个参数就不再使用了，并且对于每个进程有一个独立的信号队列，这个队列的大小可以用RLIMIT_SIGPENDING参数调节。当这个队列过于拥塞，nginx就放弃它并且开始使用poll方法来处理连接直到恢复正常。

/dev/poll-高效的方法，使用于Solaris711/99+,HP/UX11.22+(eventport),IRIX6.5.15+和Tru64UNIX5.1A+.

eventport-高效的方法，使用于Solaris10.为了防止出现内核崩溃的问题，有必要安装这个安全补丁。

在linux下面，只有epoll是高效的方法。

下面再来看看epoll到底是如何高效的

Epoll是Linux内核为处理大批量句柄而作了改进的poll。要使用epoll只需要这三个系统调用：epoll_create(2)，epoll_ctl(2)，epoll_wait(2)。它是在2.5.44内核中被引进的(epoll(4)isanewAPIintroducedinLinuxkernel2.5.44)，在2.6内核中得到广泛应用。

epoll的优点

支持一个进程打开大数目的socket描述符(FD)

select最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。不过epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat/proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

IO效率不随FD数目增加而线性下降

传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idleconnections模拟WAN环境,epoll的效率就远在select/poll之上了。

使用mmap加速内核与用户空间的消息传递。

这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工mmap这一步的。

内核微调

这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小---通过echoXXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。

以上这些epoll内容，参考epoll_互动百科

在我128M的vps上，我查看了一下，file-max的数量已经达到11945

应该说确实比apache的方式要好，而且资源占用也