深刻了解epoll (轉)

1、 介紹

Epoll 是一種高效的管理socket的模型，相對於select和poll來講具備更高的效率和易用性。傳統的select以及poll的效率會由於 socket數量的線形遞增而致使呈二次乃至三次方的降低，而epoll的性能不會隨socket數量增長而降低。標準的linux-2.4.20內核不 支持epoll，須要打patch。本文主要從linux-2.4.32和linux-2.6.10兩個內核版本介紹epoll。
2、 Epoll的使用
epoll用到的全部函數都是在頭文件sys/epoll.h中聲明的，下面簡要說明所用到的數據結構和函數：
所用到的數據結構
typedef union epoll_data {
                void ptr;
                int fd;
                __uint32_t u32;
                __uint64_t u64;
      } epoll_data_t;

      struct epoll_event {
                __uint32_t events;    / Epoll events /
                epoll_data_t data;    / User data variable /
      };
結 構體epoll_event 被用於註冊所感興趣的事件和回傳所發生待處理的事件，其中epoll_data 聯合體用來保存觸發事件的某個文件描述符相關的數據，

例如一個client鏈接到服務器，服務器經過調用accept函數能夠獲得於這個client對應 的socket文件描述符，能夠把這文件描述符賦給epoll_data的fd字段以便後面的讀寫操做在這個文件描述符上進行。

　　epoll_event 結構體的events字段是表示感興趣的事件和被觸發的事件可能的取值爲：EPOLLIN ：表示對應的文件描述符能夠讀；
EPOLLOUT：表示對應的文件描述符能夠寫；
EPOLLPRI：表示對應的文件描述符有緊急的數據可讀
EPOLLERR：表示對應的文件描述符發生錯誤；
EPOLLHUP：表示對應的文件描述符被掛斷；
EPOLLET：表示對應的文件描述符設定爲edge模式；
所用到的函數：
一、epoll_create函數
    函數聲明：int epoll_create(int size)
    該函數生成一個epoll專用的文件描述符，其中的參數是指定生成描述符的最大範圍。在linux-2.4.32內核中根據size大小初始化哈希表的大小，在linux2.6.10內核中該參數無用，使用紅黑樹管理全部的文件描述符，而不是hash。
二、epoll_ctl函數
    函數聲明：int epoll_ctl(int epfd, int op, int fd, struct epoll_event event)
    該函數用於控制某個文件描述符上的事件，能夠註冊事件，修改事件，刪除事件。
    參數：epfd：由 epoll_create 生成的epoll專用的文件描述符；
                op：要進行的操做例如註冊事件，可能的取值
　　EPOLL_CTL_ADD 註冊、
　　EPOLL_CTL_MOD 修改、
　　EPOLL_CTL_DEL 刪除
　　fd：關聯的文件描述符；
　　event：指向epoll_event的指針；
　　若是調用成功返回0,不成功返回-1
三、epoll_wait函數
函數聲明:int epoll_wait(int epfd,struct epoll_event   events,int maxevents,int timeout)
該函數用於輪詢I/O事件的發生；
參數：
epfd:由epoll_create 生成的epoll專用的文件描述符；
epoll_event:用於回傳代處理事件的數組；
maxevents:每次能處理的事件數；
timeout:等待I/O事件發生的超時值（ms）；-1永不超時，直到有事件產生才觸發，0當即返回。
返回發生事件數。-1有錯誤。

舉一個簡單的例子：

C/C++ codeint main()
{
    //聲明epoll_event結構體的變量,ev用於註冊事件,數組用於回傳要處理的事件
    struct epoll_event ev,events[20];

    epfd=epoll_create(10000); //建立epoll句柄
   
    listenfd = socket(AF_INET, SOCK_STREAM, 0);
    //把socket設置爲非阻塞方式
    setnonblocking(listenfd);
   
    bzero(&serveraddr, sizeof(serveraddr));
    serveraddr.sin_family = AF_INET;
    serveraddr.sin_addr.s_addr = INADDR_ANY;
    serveraddr.sin_port=htons(SERV_PORT);
    bind(listenfd,(struct sockaddr )&serveraddr, sizeof(serveraddr));
    listen(listenfd, 255);

    //設置與要處理的事件相關的文件描述符
    ev.data.fd=listenfd;
    //設置要處理的事件類型
    ev.events=EPOLLIN;
    //註冊epoll事件
    epoll_ctl(epfd,EPOLL_CTL_ADD,listenfd,&ev);

    for ( ; ; )
    {
      //等待epoll事件的發生
      nfds=epoll_wait(epfd,events,20,1000);
      //處理所發生的全部事件
      for(i=0;i<nfds;++i)
      {
         if(events .data.fd==listenfd)
         {
                connfd = accept(listenfd,(struct sockaddr )&clientaddr, &clilen);
                if(connfd<0)
                {
                  perror("connfd<0");
                }
                setnonblocking(connfd);
                //設置用於讀操做的文件描述符
                ev.data.fd=connfd;
                //設置用於注測的讀操做事件
                ev.events=EPOLLIN|EPOLLET;
                //註冊event
                epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev);
         }
         else if(events .events&EPOLLIN)
         {
                read_socket(events .data.fd);
                ev.data.fd=events .data.fd;
                ev.events=EPOLLIN|EPOLLOUT|EPOLLET;
                epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
         }
         else if(events .events&EPOLLOUT)
         {
                write_socket(events .data.fd);
                ev.data.fd=events .data.fd;
                ev.events=EPOLLIN|EPOLLET; //ET模式
            epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
         }
         else
         {
                perror("other event");
         }
      }
    }
}


Epoll的ET模式與LT模式
ET（Edge Triggered）與LT（Level Triggered）的主要區別能夠從下面的例子看出
eg：
1． 標示管道讀者的文件句柄註冊到epoll中；
2． 管道寫者向管道中寫入2KB的數據；
3． 調用epoll_wait能夠得到管道讀者爲已就緒的文件句柄；
4． 管道讀者讀取1KB的數據
5． 一次epoll_wait調用完成
若是是ET模式，管道中剩餘的1KB被掛起，再次調用epoll_wait，得不到管道讀者的文件句柄，除非有新的數據寫入管道。若是是LT模式，只要管道中有數據可讀，每次調用epoll_wait都會觸發。

另外一點區別就是設爲ET模式的文件句柄必須是非阻塞的。
3、 Epoll的實現
Epoll 的源文件在/usr/src/linux/fs/eventpoll.c，在module_init時註冊一個文件系統 eventpoll_fs_type，對該文件系統提供兩種操做poll和release，因此epoll_create返回的文件句柄能夠被poll、 select或者被其它epoll epoll_wait。對epoll的操做主要經過三個系統調用實現：
1． sys_epoll_create
2． sys_epoll_ctl
3． sys_epoll_wait
下面結合源碼講述這三個系統調用。
1.1 long sys_epoll_create (int size)
該 系統調用主要分配文件句柄、inode以及file結構。在linux-2.4.32內核中，使用hash保存全部註冊到該epoll的文件句柄，在該系 統調用中根據size大小分配hash的大小。具體爲不小於size，但小於2size的2的某次方。最小爲2的9次方（512），最大爲2的17次方 （128 x 1024）。在linux-2.6.10內核中，使用紅黑樹保存全部註冊到該epoll的文件句柄，size參數未使用。
1.2 long sys_epoll_ctl(int epfd, int op, int fd, struct epoll_event event)
1． 註冊句柄 op = EPOLL_CTL_ADD
註冊過程主要包括：
A．將fd插入到hash（或rbtree）中，若是原來已經存在返回-EEXIST，
B．給fd註冊一個回調函數，該函數會在fd有事件時調用，在該函數中將fd加入到epoll的就緒隊列中。
C．檢查fd當前是否已經有指望的事件產生。若是有，將其加入到epoll的就緒隊列中，喚醒epoll_wait。

2． 修改事件 op = EPOLL_CTL_MOD
修改事件只是將新的事件替換舊的事件，而後檢查fd是否有指望的事件。若是有，將其加入到epoll的就緒隊列中，喚醒epoll_wait。

3． 刪除句柄 op = EPOLL_CTL_DEL
將fd從hash（rbtree）中清除。
1.3 long sys_epoll_wait(int epfd, struct epoll_event events, int maxevents,int timeout)
若是epoll的就緒隊列爲空，而且timeout非0，掛起當前進程，引發CPU調度。
若是epoll的就緒隊列不空，遍歷就緒隊列。對隊列中的每個節點，獲取該文件已觸發的事件，判斷其中是否有咱們期待的事件，若是有，將其對應的epoll_event結構copy到用戶events。

revents = epi->file->f_op->poll(epi->file, NULL);
epi->revents = revents & epi->event.events;
if (epi->revents) {
……
copy_to_user;
……
}
須要注意的是，在LT模式下，把符合條件的事件copy到用戶空間後，還會把對應的文件從新掛接到就緒隊列。因此在LT模式下，若是一次epoll_wait某個socket沒有read/write完全部數據，下次epoll_wait還會返回該socket句柄。
4、 使用epoll的注意事項
1. ET模式比LT模式高效，但比較難控制。
2. 若是某個句柄期待的事件不變，不須要EPOLL_CTL_MOD，但每次讀寫後將該句柄modify一次有助於提升穩定性，特別在ET模式。
3. socket關閉後最好將該句柄從epoll中delete（EPOLL_CTL_DEL），雖然epoll自身有處理，但會使epoll的hash的節點數增多，影響搜索hash的速度。
  
Q：網絡服務器的瓶頸在哪？
A：IO效率。

在 你們苦苦的爲在線人數的增加而致使的系統資源吃緊上的問題正在發愁的時候，Linux 2.6內核中提供的System Epoll爲咱們提供了一套完美的解決方案。傳統的select以及poll的效率會由於在線人數的線形遞增而致使呈二次乃至三次方的降低，這些直接致使 了網絡服務器能夠支持的人數有了個比較明顯的限制。

自從Linux提供了/dev/epoll的設備以及後來2.6內核中對/dev /epoll設備的訪問的封裝（System Epoll）以後，這種現象獲得了大大的緩解，若是說幾個月前，你們還對epoll不熟悉，那麼如今來講的話，epoll的應用已經獲得了大範圍的普及。

那麼究竟如何來使用epoll呢？其實很是簡單。
經過在包含一個頭文件#include 以及幾個簡單的API將能夠大大的提升你的網絡服務器的支持人數。

首 先經過create_epoll(int maxfds)來建立一個epoll的句柄，其中maxfds爲你epoll所支持的最大句柄數。這個函數會返回一個新的epoll句柄，以後的全部操做 將經過這個句柄來進行操做。在用完以後，記得用close()來關閉這個建立出來的epoll句柄。

以後在你的網絡主循環裏面，每一幀的調用epoll_wait(int epfd, epoll_event events, int max events, int timeout)來查詢全部的網絡接口，看哪個能夠讀，哪個能夠寫了。基本的語法爲：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其 中kdpfd爲用epoll_create建立以後的句柄，events是一個epoll_event的指針，當epoll_wait這個函數操做成功之 後，epoll_events裏面將儲存全部的讀寫事件。max_events是當前須要監聽的全部socket句柄數。最後一個timeout是 epoll_wait的超時，爲0的時候表示立刻返回，爲-1的時候表示一直等下去，直到有事件範圍，爲任意正整數的時候表示等這麼長的時間，若是一直沒 有事件，則範圍。通常若是網絡主循環是單獨的線程的話，能夠用-1來等，這樣能夠保證一些效率，若是是和主邏輯在同一個線程的話，則能夠用0來保證主循環 的效率。

epoll_wait範圍以後應該是一個循環，遍利全部的事件：

C/C++ codefor(n = 0; n < nfds; ++n) {
            if(events[n].data.fd == listener) { //若是是主socket的事件的話，則表示有新鏈接進入了，進行新鏈接的處理。
                   client = accept(listener, (struct sockaddr ) &local,
                                 &addrlen);
                   if(client < 0){
                     perror("accept");
                     continue;
                   }
                   setnonblocking(client); // 將新鏈接置於非阻塞模式
                   ev.events = EPOLLIN | EPOLLET; // 而且將新鏈接也加入EPOLL的監聽隊列。
注意，這裏的參數EPOLLIN | EPOLLET並無設置對寫socket的監聽，若是有寫操做的話，這個時候epoll是不會返回事件的，若是要對寫操做也監聽的話，應該是EPOLLIN | EPOLLOUT | EPOLLET
                   ev.data.fd = client;
                   if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
//   設置好event以後，將這個新的event經過epoll_ctl加入到epoll的監聽隊列裏面，這裏用EPOLL_CTL_ADD來加一個新的 epoll事件，經過EPOLL_CTL_DEL來減小一個epoll事件，經過EPOLL_CTL_MOD來改變一個事件的監聽方式。
                     fprintf(stderr, "epoll set insertion error: fd=d0,
                               client);
                     return -1;
                   }
            }
            else // 若是不是主socket的事件的話，則表明是一個用戶socket的事件，則來處理這個用戶socket的事情，好比說read(fd,xxx)之類的，或者一些其餘的處理。
                   do_use_fd(events[n].data.fd);
}



對，epoll的操做就這麼簡單，總共不過4個API：epoll_create, epoll_ctl, epoll_wait和close。

 

 

Linux 2.6內核中提升網絡I/O性能的新方法

一、爲何select是落後的？
首先，在Linux內核中，select所用到的FD_SET是有限的，即內核中有個參數__FD_SETSIZE定義了每一個FD_SET的句柄個數，在我用的2.6.15-25-386內核中，該值是1024，搜索內核源代碼獲得：
include/linux/posix_types.h:#define __FD_SETSIZE 1024
也就是說，若是想要同時檢測1025個句柄的可讀狀態是不可能用select實現的。或者同時檢測1025個句柄的可寫狀態也是不可能的。
其次，內核中實現select是用輪詢方法，即每次檢測都會遍歷全部FD_SET中的句柄，顯然，select函數執行時間與FD_SET中的句柄個數有一個比例關係，即select要檢測的句柄數越多就會越費時。
固然，在前文中我並無說起poll方法，事實上用select的朋友必定也試過poll，我我的以爲select和poll大同小異，我的偏好於用select而已。
二、2.6內核中提升I/O性能的新方法epoll
epoll是什麼？按照man手冊的說法：是爲處理大批量句柄而做了改進的poll。要使用epoll只須要這三個系統調用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
固然，這不是2.6內核纔有的，它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)

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網 卡驅動架構。
epoll的使用
使人高興的是，2.6內核的epoll比其2.5開發版本的/dev/epoll簡潔了許多，因此，大部分狀況下，強大的東西每每是簡單的。惟一有點麻煩是epoll有2種工做方式:LT和ET。
LT(level triggered)是缺省的工做方式，而且同時支持block和no-block socket.在這種作法中，內核告訴你一個文件描述符是否就緒了，而後你能夠對這個就緒的fd進行IO操做。若是你不做任何操做，內核仍是會繼續通知你 的，因此，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的表明．
ET (edge-triggered)是高速工做方式，只支持no-block socket。在這種模式下，當描述符從未就緒變爲就緒時，內核經過epoll告訴你。而後它會假設你知道文件描述符已經就緒，而且不會再爲那個文件描述 符發送更多的就緒通知，直到你作了某些操做致使那個文件描述符再也不爲就緒狀態了(好比，你在發送，接收或者接收請求，或者發送接收的數據少於必定量時致使 了一個EWOULDBLOCK 錯誤）。可是請注意，若是一直不對這個fd做IO操做(從而致使它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍須要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用，具體用法請參考http://www.xmailserver.org/linux-patches/nio-improve.html ，
在http://www.kegel.com/rn/也有一個完整的例子，你們一看就知道如何使用了
Leader/follower模式線程pool實現，以及和epoll的配合

在Linux上開發網絡服務器的一些相關細節:poll與epoll
　　隨着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複雜，監控少許描述符並不是它的長處。