轉自：http://blog.sina.com.cn/s/blog_5eaf88f10100gkrq.html
Nginx use參數分析對比
下圖對比了poll select epoll和kqueue的性能。select和poll是一個級別的，epoll和kqueue是一個級別的，相差不多。epoll用在linux上,kqueue用在bsd上,不能物理上共存。如果你的服務器cpu較好，linux內核新，可考慮用epoll.
如何選擇：
freebsd ：kqueue
linux 2.6 ：epoll
測試分析
兩個東西極其相似，寫好了一個之后，移到別外一個平台下，只要稍作修改就可以了，原理是一樣，個人認為，從功能角度來盾kqueue比epoll靈活得多。在寫kqueue的時候，內核幫你考慮好了不少東西。但是從效率來看，從我作的壓力測試來看epoll比kqueue強。看看我的實驗結果吧
客戶端： linux ,P3，256M ，pthread多線程程序，開1萬個線程，可是實際運行結果是，在linux2.4上只能打開4000多個線程的時候就報資源不足，郁悶了好久，不知道是什么資源，最大打開文件數是夠了，內存也夠（通過設置16k的棧空間）。后來把客戶端移到linux2.6內核下，很快開出1萬個線程來了。
epoll服務器端：P3，256M，在一萬個並發線程下，面不改色，有條不紊地處理着數據，並發數能達到8000個連接。
kqueue 服務器端：結果比較失望，在只能一條隊列的情況下，並發數只能到2000，然后在客戶端的讀取數據時就會出現"connect reset by peer"的錯誤。后來改用了兩條隊列，一條用來接收新連接，一條用來處理原有的連接。在這種情況下，並發數也只能到3000，然后又會陸陸續續出現連接的錯誤。
Nginx優化use參數epoll,kqueue,rtsig,eventport,poll和select的區別
參考：http://wiki.nginx.org/NginxOptimizations
Nginx supports the following methods of treating the connections, which can be assigned by the usedirective:
select - standard method. Compiled by default, if the current platform does not have a more effective method. You can enable or disable this module by using configuration parameters --with-select_module and --without-select_module.
poll - standard method. Compiled by default, if the current platform does not have a more effective method. You can enable or disable this module by using configuration parameters --with-poll_module and --without-poll_module.
kqueue - the effective method, used on FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 and MacOS X. With dual-processor machines running MacOS X using kqueue can lead to kernel panic.
epoll - the effective method, used on Linux 2.6+. In some distrubutions, like SuSE 8.2, there are patches for supporting epoll by kernel version 2.4.
rtsig - real time signals, the executable used on Linux 2.2.19+. By default no more than 1024 POSIX realtime (queued) signals can be outstanding in the entire system. This is insufficient for highly loaded servers; it's therefore necessary to increase the queue size by using the kernel parameter /proc/sys/kernel/rtsig-max However, starting with Linux 2.6.6-mm2, this parameter is no longer available, and for each process there is a separate queue of signals, the size of which is assigned by RLIMIT_SIGPENDING. When the queue becomes overcrowded, nginx discards it and begins processing connections using the poll method until the situation normalizes.
/dev/poll - the effective method, used on Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ and Tru64 UNIX 5.1A+.
eventport - the effective method, utilized in Solaris 10. To avoid kernel panic, it is necessary to install this security patch.