随着2.6内核对epoll的彻底支持，网络上不少的文章和示例代码都提供了这样一个信息：使用epoll代替传统的poll能给网络服务应用带来性能上的提高。但大多文章里关于性能提高的缘由解释的较少，这里我将试分析一下内核（2.6.21.1）代码中poll与epoll的工做原理，而后再经过一些测试数据来对比具体效果。

       POLL：

       先说poll，poll或select为大部分Unix/Linux程序员所熟悉，这俩个东西原理相似，性能上也不存在明显差别，但select对所监控的文件描述符数量有限制，因此这里选用poll作说明。
   
       poll是一个系统调用，其内核入口函数为sys_poll，sys_poll几乎不作任何处理直接调用do_sys_poll，do_sys_poll的执行过程能够分为三个部分：

       1，将用户传入的pollfd数组拷贝到内核空间，由于拷贝操做和数组长度相关，时间上这是一个O（n）操做，这一步的代码在do_sys_poll中包括从函数开始到调用do_poll前的部分。

       2，查询每一个文件描述符对应设备的状态，若是该设备还没有就绪，则在该设备的等待队列中加入一项并继续查询下一设备的状态。查询完全部设备后若是没有一个设备就绪，这时则须要挂起当前进程等待，直到设备就绪或者超时，挂起操做是经过调用schedule_timeout执行的。设备就绪后进程被通知继续运行，这时再次遍历全部设备，以查找就绪设备。这一步由于两次遍历全部设备，时间复杂度也是O（n），这里面不包括等待时间。相关代码在do_poll函数中。

       3，将得到的数据传送到用户空间并执行释放内存和剥离等待队列等善后工做，向用户空间拷贝数据与剥离等待队列等操做的的时间复杂度一样是O（n），具体代码包括do_sys_poll函数中调用do_poll后到结束的部分。

       EPOLL：

       接下来分析epoll，与poll/select不一样，epoll再也不是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样作的好处。

       先来看sys_epoll_create(epoll_create对应的内核函数），这个函数主要是作一些准备工做，好比建立数据结构，初始化数据并最终返回一个文件描述符（表示新建立的虚拟epoll文件），这个操做能够认为是一个固定时间的操做。

        epoll是作为一个虚拟文件系统来实现的，这样作至少有如下两个好处：

        1，能够在内核里维护一些信息，这些信息在屡次epoll_wait间是保持的，好比全部受监控的文件描述符。

        2， epoll自己也能够被poll/epoll;

       具体epoll的虚拟文件系统的实现和性能分析无关，再也不赘述。

       在sys_epoll_create中还能看到一个细节，就是epoll_create的参数size在现阶段是没有意义的，只要大于零就行。

       接着是sys_epoll_ctl(epoll_ctl对应的内核函数），须要明确的是每次调用sys_epoll_ctl只处理一个文件描述符，这里主要描述当op为EPOLL_CTL_ADD时的执行过程，sys_epoll_ctl作一些安全性检查后进入ep_insert，ep_insert里将 ep_poll_callback作为回掉函数加入设备的等待队列（假定这时设备还没有就绪），因为每次poll_ctl只操做一个文件描述符，所以也能够认为这是一个O(1)操做

        ep_poll_callback函数很关键，它在所等待的设备就绪后被系统回掉，执行两个操做：

       1，将就绪设备加入就绪队列，这一步避免了像poll那样在设备就绪后再次轮询全部设备找就绪者，下降了时间复杂度，由O（n）到O（1）;
   
       2，唤醒虚拟的epoll文件;

       最后是sys_epoll_wait，这里实际执行操做的是ep_poll函数。该函数等待将进程自身插入虚拟epoll文件的等待队列，直到被唤醒（见上面ep_poll_callback函数描述），最后执行ep_events_transfer将结果拷贝到用户空间。因为只拷贝就绪设备信息，因此这里的拷贝是一个O(1）操做。

       还有一个让人关心的问题就是epoll对EPOLLET的处理，即边沿触发的处理，粗略看代码就是把一部分水平触发模式下内核作的工做交给用户来处理，直觉上不会对性能有太大影响，感兴趣的朋友欢迎讨论。

       POLL/EPOLL对比：

       表面上poll的过程能够看做是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系统调用构成，实际上epoll将poll分红若干部分实现的缘由正是由于服务器软件中使用poll的特色（好比Web服务器）：

       1，须要同时poll大量文件描述符;

       2，每次poll完成后就绪的文件描述符只占全部被poll的描述符的不多一部分。

       3，先后屡次poll调用对文件描述符数组（ufds）的修改只是很小;

       传统的poll函数至关于每次调用都重起炉灶，从用户空间完整读入ufds，完成后再次彻底拷贝到用户空间，另外每次poll都须要对全部设备作至少作一次加入和删除等待队列操做，这些都是低效的缘由。

        epoll将以上状况都细化考虑，不须要每次都完整读入输出ufds，只需使用epoll_ctl调整其中一小部分，不须要每次epoll_wait都执行一次加入删除等待队列操做，另外改进后的机制使的没必要在某个设备就绪后搜索整个设备数组进行查找，这些都能提升效率。另外最明显的一点，从用户的使用来讲，使用epoll没必要每次都轮询全部返回结果已找出其中的就绪部分，O（n）变O（1），对性能也提升很多。

       此外这里还发现一点，是否是将epoll_ctl改为一次能够处理多个fd（像semctl那样）会提升些许性能呢？特别是在假设系统调用比较耗时的基础上。不过关于系统调用的耗时问题还会在之后分析。

       POLL/EPOLL测试数据对比：

       测试的环境：我写了三段代码来分别模拟服务器，活动的客户端，僵死的客户端，服务器运行于一个自编译的标准2.6.11内核系统上，硬件为 PIII933，两个客户端各自运行在另外的PC上，这两台PC比服务器的硬件性能要好，主要是保证能轻易让服务器满载，三台机器间使用一个100M交换机链接。

       服务器接受并poll全部链接，若是有request到达则回复一个response，而后继续poll。

       活动的客户端（Active Client）模拟若干并发的活动链接，这些链接不间断的发送请求接受回复。

       僵死的客户端（zombie）模拟一些只链接但不发送请求的客户端，其目的只是占用服务器的poll描述符资源。

        测试过程：保持10个并发活动链接，不断的调整僵并发链接数，记录在不一样比例下使用poll与epoll的性能差异。僵死并发链接数根据比例分别是：0，10，20，40，80，160，320，640，1280，2560，5120，10240。

       下图中横轴表示僵死并发链接与活动并发链接之比，纵轴表示完成40000次请求回复所花费的时间，以秒为单位。红色线条表示poll数据，绿色表示 epoll数据。能够看出，poll在所监控的文件描述符数量增长时，其耗时呈线性增加，而epoll则维持了一个平稳的状态，几乎不受描述符个数影响。

       在监控的全部客户端都是活动时，poll的效率会略高于epoll（主要在原点附近，即僵死并发链接为0时，图上不易看出来），究竟epoll实现比poll复杂，监控少许描述符并不是它的长处。

       测试代码及具体数据能够从这里得到，欢迎讨论。
 
 
select()系统调用提供一个机制来实现同步多元I/O：

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int select (int n,
fd_set *readfds,
fd_set *writefds,
fd_set *exceptfds,
struct timeval *timeout);

FD_CLR(int fd, fd_set *set);
FD_ISSET(int fd, fd_set *set);
FD_SET(int fd, fd_set *set);
FD_ZERO(fd_set *set);

调用select()将阻塞，直到指定的文件描述符准备好执行I/O，或者可选参数timeout指定的时间已通过去。
监视的文件描述符分为三类set，每一种对应等待不一样的事件。readfds中列出的文件描述符被监视是否有数据可供读取（若是读取操做完成则不会阻塞）。writefds中列出的文件描述符则被监视是否写入操做完成而不阻塞。最后，exceptfds中列出的文件描述符则被监视是否发生异常，或者没法控制的数据是否可用（这些状态仅仅应用于套接字）。这三类set能够是NULL，这种状况下select()不监视这一类事件。
select()成功返回时，每组set都被修改以使它只包含准备好I/O的文件描述符。例如，假设有两个文件描述符，值分别是7和9，被放在readfds中。当select()返回时，若是7仍然在set中，则这个文件描述符已经准备好被读取而不会阻塞。若是9已经不在set中，则读取它将可能会阻塞（我说多是由于数据可能正好在select返回后就可用，这种状况下，下一次调用select()将返回文件描述符准备好读取）。
第一个参数n，等于全部set中最大的那个文件描述符的值加1。所以，select()的调用者负责检查哪一个文件描述符拥有最大值，而且把这个值加1再传递给第一个参数。
timeout参数是一个指向timeval结构体的指针，timeval定义以下：
#include <sys/time.h>
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* 10E-6 second */
};

若是这个参数不是NULL，则即便没有文件描述符准备好I/O，select()也会在通过tv_sec秒和tv_usec微秒后返回。当select()返回时，timeout参数的状态在不一样的系统中是未定义的，所以每次调用select()以前必须从新初始化timeout和文件描述符set。实际上，当前版本的Linux会自动修改timeout参数，设置它的值为剩余时间。所以，若是timeout被设置为5秒，而后在文件描述符准备好以前通过了3秒，则这一次调用select()返回时tv_sec将变为2。
若是timeout中的两个值都设置为0，则调用select()将当即返回，报告调用时全部未决的事件，但不等待任何随后的事件。
文件描述符set不会直接操做，通常使用几个助手宏来管理。这容许Unix系统以本身喜欢的方式来实现文件描述符set。但大多数系统都简单地实现set为位数组。FD_ZERO移除指定set中的全部文件描述符。每一次调用select()以前都应该先调用它。
fd_set writefds;
FD_ZERO(&writefds);

FD_SET添加一个文件描述符到指定的set中，FD_CLR则从指定的set中移除一个文件描述符：
FD_SET(fd, &writefds); /* add 'fd' to the set */
FD_CLR(fd, &writefds); /* oops, remove 'fd' from the set */

设计良好的代码应该永远不使用FD_CLR，并且实际状况中它也确实不多被使用。
FD_ISSET测试一个文件描述符是否指定set的一部分。若是文件描述符在set中则返回一个非0整数，不在则返回0。FD_ISSET在调用select()返回以后使用，测试指定的文件描述符是否准备好相关动做：
if (FD_ISSET(fd, &readfds))
/* 'fd' is readable without blocking! */

由于文件描述符set是静态建立的，它们对文件描述符的最大数目强加了一个限制，可以放进set中的最大文件描述符的值由FD_SETSIZE指定。在Linux中，这个值是1024。本章后面咱们还将看到这个限制的衍生物。
返回值和错误代码
select()成功时返回准备好I/O的文件描述符数目，包括全部三个set。若是提供了timeout，返回值多是0；错误时返回-1，而且设置errno为下面几个值之一：
EBADF
给某个set提供了无效文件描述符。
EINTR
等待时捕获到信号，能够从新发起调用。
EINVAL
参数n为负数，或者指定的timeout非法。
ENOMEM
不够可用内存来完成请求。
--------------------------------------------------------------------------------------------------------------
poll()系统调用是System V的多元I/O解决方案。它解决了select()的几个不足，尽管select()仍然常用（多数仍是出于习惯，或者打着可移植的名义）：
#include <sys/poll.h>
int poll (struct pollfd *fds, unsigned int nfds, int timeout);

和select()不同，poll()没有使用低效的三个基于位的文件描述符set，而是采用了一个单独的结构体pollfd数组，由fds指针指向这个组。pollfd结构体定义以下：
#include <sys/poll.h>

struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};

每个pollfd结构体指定了一个被监视的文件描述符，能够传递多个结构体，指示poll()监视多个文件描述符。每一个结构体的events域是监视该文件描述符的事件掩码，由用户来设置这个域。revents域是文件描述符的操做结果事件掩码。内核在调用返回时设置这个域。events域中请求的任何事件均可能在revents域中返回。合法的事件以下：
POLLIN
有数据可读。
POLLRDNORM
有普通数据可读。
POLLRDBAND
有优先数据可读。
POLLPRI
有紧迫数据可读。
POLLOUT
写数据不会致使阻塞。
POLLWRNORM
写普通数据不会致使阻塞。
POLLWRBAND
写优先数据不会致使阻塞。
POLLMSG
SIGPOLL消息可用。

此外，revents域中还可能返回下列事件：
POLLER
指定的文件描述符发生错误。
POLLHUP
指定的文件描述符挂起事件。
POLLNVAL
指定的文件描述符非法。

这些事件在events域中无心义，由于它们在合适的时候老是会从revents中返回。使用poll()和select()不同，你不须要显式地请求异常状况报告。
POLLIN | POLLPRI等价于select()的读事件，POLLOUT | POLLWRBAND等价于select()的写事件。POLLIN等价于POLLRDNORM | POLLRDBAND，而POLLOUT则等价于POLLWRNORM。
例如，要同时监视一个文件描述符是否可读和可写，咱们能够设置events为POLLIN | POLLOUT。在poll返回时，咱们能够检查revents中的标志，对应于文件描述符请求的events结构体。若是POLLIN事件被设置，则文件描述符能够被读取而不阻塞。若是POLLOUT被设置，则文件描述符能够写入而不致使阻塞。这些标志并非互斥的：它们可能被同时设置，表示这个文件描述符的读取和写入操做都会正常返回而不阻塞。
timeout参数指定等待的毫秒数，不管I/O是否准备好，poll都会返回。timeout指定为负数值表示无限超时；timeout为0指示poll调用当即返回并列出准备好I/O的文件描述符，但并不等待其它的事件。这种状况下，poll()就像它的名字那样，一旦选举出来，当即返回。
返回值和错误代码
成功时，poll()返回结构体中revents域不为0的文件描述符个数；若是在超时前没有任何事件发生，poll()返回0；失败时，poll()返回-1，并设置errno为下列值之一：
EBADF
一个或多个结构体中指定的文件描述符无效。
EFAULT
fds指针指向的地址超出进程的地址空间。
EINTR
请求的事件以前产生一个信号，调用能够从新发起。
EINVAL
nfds参数超出PLIMIT_NOFILE值。
ENOMEM
可用内存不足，没法完成请求。
--------------------------------------------------------------------------------------------------------------
以上内容来自《OReilly.Linux.System.Programming - Talking.Directly.to.the.Kernel.and.C.Library.2007》
--------------------------------------------------------------------------------------------------------------
epoll的优势：
1.支持一个进程打开大数目的socket描述符(FD)
    select 最不能忍受的是一个进程所打开的FD是有必定限制的，由FD_SETSIZE设置，默认值是2048。对于那些须要支持的上万链接数目的IM服务器来讲显然太少了。这时候你一是能够选择修改这个宏而后从新编译内核，不过资料也同时指出这样会带来网络效率的降低，二是能够选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面建立进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，因此也不是一种完美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大能够打开文件的数目，这个数字通常远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目能够cat /proc/sys/fs/file-max察看,通常来讲这个数目和系统内存关系很大。
2.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,效率相比还有稍微的降低。可是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
3.使用mmap加速内核与用户空间的消息传递。
    这点实际上涉及到epoll的具体实现了。不管是select,poll仍是epoll都须要内核把FD消息通知给用户空间，如何避免没必要要的内存拷贝就很重要，在这点上，epoll是经过内核于用户空间mmap同一块内存实现的。而若是你想我同样从2.5内核就关注epoll的话，必定不会忘记手工 mmap这一步的。
4.内核微调
    这一点其实不算epoll的优势了，而是整个linux平台的优势。也许你能够怀疑linux平台，可是你没法回避linux平台赋予你微调内核的能力。好比，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么能够在运行时期动态调整这个内存pool(skb_head_pool)的大小--- 经过echo XXXX>/proc/sys/net/core/hot_list_length完成。再好比listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也能够根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每一个数据包自己大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。