如何高效處理多個socket I/O的讀寫，是提高服務器性能的重點問題。unix-like下面，現有機制有select,poll, epoll,kqueue,/dev/poll兩大類。
Select有個缺點，它用fd_set管理所有要監視的I/O句柄，但是fd_set是一個位數組，只能接受句柄號小于FD_SETSIZE（默認1024）的句柄，雖然進程默認句柄號都是小于1024的，但是可以通過ulimit –n來修改，尤其是連接數超過1024時必需這么做（實際可能更少），如果要將大于1024的句柄放入fd_set，就可能發生數組越界程序崩潰的場面。
Poll雖然解決了FD_SETSIZE問題，但是它和select一樣，都有性能上的瓶頸。它們都會隨著連接數的增加性能直線下降。這主要有兩個原因，其一是每次select/poll操作，kernel都會建立一個當前線程關心的事件列表，并讓線程阻塞在這個列表上，這是很耗時的操作。其二是每次select/poll返回后，線程都要掃描所有句柄來dispatch已發生的事件，這也是很耗時的。當連接數巨大時，這種消耗積累起來，就很受不了。
為了解決select/poll的性能問題，unix-like系統上開發出了三套新的利器epoll，kqueue，/dev/poll，其中epoll是linux的，kqueue是freebsd的，/dev/poll是Solaris上的，它們是select/poll的替代品。它們的設計就是針對select/poll的性能問題，主要避免 1。每次調用都建立事件等待列表，取而代之建立長期的事件關注列表，這個列表可通過句柄（比如epfd）來增加和刪除事件。2。調用返回之后，不再需要遍歷所有句柄進行分發，內核會直接返回當前已發生的事件。不用說，性能在select, poll基礎上有了大幅提升。
要注意的是，凡是使用readiness notification（LT)或者readiness change notification（ET)機制，都應該配合非阻塞I/O，因為這種事件通知，并不一定表示文件描述符真正就緒，如果收到通知之后去read，很有可能進入阻塞狀態，這會嚴重影響服務器的并發性能，同時對ET模式，不能漏掉任何事件的處理，并且每次都應該讀到socket返回EWOULDBLOCK為止，不然這個socket之后會永遠保持沉默。