多路IO複用模型 select epoll 等

同步阻塞IO在等待資料就緒上花去太多時間，而傳統的同步非阻塞IO雖然不會阻塞進程，但是結合輪詢來判斷資料是否就緒仍然會耗費大量的CPU時間。

多路IO複用提供了對大量檔案描述符進行就緒檢查的高效能方案。

 

select

select誕生於4.2BSD，在幾乎所有平台上都支援，其良好的跨平台支援是它的主要的也是為數不多的優點之一。

select的缺點（1）單個進程能夠監視的檔案描述符的數量存在最大限制（2）select需要複製大量的控制代碼資料結構，產生巨大的開銷 （3）select返回的是含有整個控制代碼的列表，應用程式需要遍曆整個列表才能發現哪些控制代碼發生了事件（4）select的觸發方式是水平觸發，應用程式如果沒有完成對一個已經就緒的檔案描述符進行IO操作，那麼之後每次select調用還是會將這些檔案描述符通知進程。相對應方式的是邊緣觸發。

 

poll

poll 誕生於UNIX System V Release 3，那時AT&T已經停止了UNIX的原始碼授權，所以顯然也不會直接使用BSD的select，所以AT&T自己實現了一個和select沒有多大差別的poll。

poll和select是名字不同的孿生兄弟，除了沒有監視檔案數量的限制，select後面3條缺點同樣適用於poll。

面對select和poll的缺陷，不同的OS做出了不同的解決方案，可謂百花齊放。不過他們至少完成了下面兩點超越，一是核心長期維護一個事件關注列表，我們只需要修改這個列表，而不需要將控制代碼資料結構複製到核心中；二是直接返回事件列表，而不是所有控制代碼列表。

/dev/poll

Sun在Solaris中提出了新的實現方案，它使用了虛擬/dev/poll裝置，開發人員可以將要監視的檔案描述符加入這個裝置，然後通過ioctl()來等待事件通知。

/dev/epoll

名為/dev/epoll的裝置以補丁的方式出現在Linux2.4中，它提供了類似/dev/poll的功能，並且在一定程度上使用mmap提高了效能。

 

kqueue

FreeBSD實現了kqueue，可以支援水平觸發和邊緣觸發，效能和下面要提到的epoll非常接近。

 

epoll

epoll誕生於Linux 2.6核心，被公認為是Linux2.6下效能最好的多路IO複用方法。

 

int epoll_create(int size)

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)

• epoll_create 建立 kernel 中的關注事件表，相當於建立 fd_set
• epoll_ctl 修改這個表，相當於 FD_SET 等操作 
• epoll_wait等待 I/O事件發生，相當於 select/poll 函數 

epoll支援水平觸發和邊緣觸發，理論上來說邊緣觸發效能更高，但是使用更加複雜，因為任何意外的丟失事件都會造成請求處理錯誤。Nginx就使用了epoll的邊緣觸發模型。

這裡提一下水平觸發和邊緣觸發就緒通知的區別，這兩個詞來源於電腦硬體設計。它們的區別是只要控制代碼滿足某種狀態，水平觸發就會發出通知；而只有當控制代碼狀態改變時，邊緣觸發才會發出通知。例如一個socket經過長時間等待後接收到一段100k的資料，兩種觸發方式都會向程式發出就緒通知。假設程式從這個socket中讀取了50k資料，並再次調用監聽函數，水平觸發依然會發出就緒通知，而邊緣觸發會因為socket“有資料可讀”這個狀態沒有發生變化而不發出通知且陷入長時間的等待。

因此在使用邊緣觸發的 api 時，要注意每次都要讀到 socket返回 EWOULDBLOCK為止

 

=================================================================================

 

http://bbs.linuxpk.com/thread-43628-1-1.html

我們先來介紹下nginx  nginx :
支援高並發串連．官方測試的是５ｗ並發串連但在實際生產中可製成2-4w並發串連數,得益於nginx使用最新的epoll(linux 2.6核心)和kqueue(freebsd)網路I/O模型.而apache使用的則是傳統的select模型,其比較穩定的prefork模式為多進程模式,需要經常派生子進程,所消耗的CPU等伺服器資源要比nginx高的多.

select 和epoll效率差的原因: select是輪詢、epoll是觸發式的，所以效率高。單單這樣講,那能懂了才見鬼了.好...我們暫且客觀的記住這句話.

先說Select: 
1.Socket數量限制:該模式可操作的Socket數由FD_SETSIZE決定,核心預設32*32=1024. 
2.操作限制:通過遍曆FD_SETSIZE(1024)個Socket來完成調度,不管哪個Socket是活躍的,都遍曆一遍. 

後說Poll: 
1.Socket數量幾乎無限制:該模式下的Socket對應的fd列表由一個數組來儲存,大小不限(預設4k). 
2.操作限制:同Select. 

再說:Epoll: 
1.Socket數量無限制:同Poll 
2.操作無限制:基於核心提供的反射模式,有活躍Socket時,核心訪問該Socket的callback,不需要遍曆輪詢. 但是當所有Socket都活躍的時候,這時候所有的callback都被喚醒,會導致資源的競爭.既然都是要處理所有的Socket,那麼遍曆是最簡單最有效實現方式.


舉例來說: 
對於IM伺服器,伺服器和伺服器之間都是長連結,但數量不多,一般一台60\70個,比如採用ICE這種架構設計,但請求相當頻繁和密集,這時候通過反射喚醒callback不一定比用select去遍曆處理更好. 
對於web portal(門戶)伺服器,都是瀏覽器用戶端發起的http短連結請求,數量很大,好一點的網站動輒每分鐘上千個請求過來,同時伺服器端還有更多的閑置等待逾時的Socket,這時候沒必要把全部的Socket都遍曆處理,因為那些等待逾時的請求是大多數的,這樣用Epoll會更好.

支援一個進程開啟大數目的socket描述符
　 　select 最不能忍受的是一個進程所開啟的FD是有一定限制的，由FD_SETSIZE設定，預設值是1024。對於那些需要支援的上萬串連數目的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,效率相比還有稍微的下降。但是一旦使用idle connections類比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）的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數（TCP完成3次握手 的資料包隊列長度），也可以根據你平台記憶體大小動態調整。更甚至在一個資料包面數目巨大但同時每個資料包本身大小卻很小的特殊系統上嘗試最新的NAPI網 卡驅動架構。

select模式低效的原因
select 模式低效是由select的定義所決定的，與作業系統實現無關，任何核心在實現select時必須做輪循，才能知道這些socket的情況，這是會消耗 cpu的。此外，當你擁有一個很大socket集的時候，儘管任一時間只有小部分的socket是"活躍"的，但每次你都不得不將所有的socket填入到一個FD_SET中，這也會消耗一些cpu，並且當select返回後，處理業務時你可能還需要做“上下文映射”，同樣也會有一些效能影響，因此 select比epoll相對低效。
epoll的適用情景就是大量的socket，但是活躍多不是很高的情況。   
還有 kqueue，實際上有不少伺服器是基於 BSD 開發的
kqueue 和 epoll 類似，據說效率上稍微高一些，不過沒比較過