epoll 相對于select的優勢

這個問題至今才去查，是因為我需要用的地方真的不是很多，學習了那麼多年，不知道自己究竟學了什麼，覺得自己的優勢就是針對特定知識點都熟悉點，一整套的軟體架構沒有搞過。

再總結一點select的不足點：

epoll比select牛逼的地方

支援一個程序打開大數目的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這一步的。