下圖對(duì)比了poll select
epoll和kqueue的性能,。select和poll是一個(gè)級(jí)別的，epoll和kqueue是一個(gè)級(jí)別的,，相差不多,。epoll用在linux上,kqueue用在bsd上,不能物理上共存。如果你的服務(wù)器cpu較好,，linux內(nèi)核新,，可考慮用epoll.
X
Basically what this says is that FreeBSD's kqueue out-performs
Linux's epoll by a bit.
select() and poll() are anachronisms.
As an aside, libevent rocks and I use it all the time for writing
portable network code. It allows you to use the best available I/O
multiplexing functionality on a given platform without having to
write seperate code for all of them via a fairly coder-friendly
API, and has a nice little async DNS library with it to boot.
Macro的某個(gè)機(jī)器（centos5.3,e7300）的nginx從默認(rèn)的沒(méi)有use設(shè)置改為use epoll后實(shí)際情況 load
average: 0.14, 0.21, 0.26，負(fù)載似乎減少了0.1,，可能并發(fā)請(qǐng)求量不大,，暫時(shí)沒(méi)看出有多大效果 ：
Active connections: 2548 server accepts handled reques
ts 35279765 35279765 59264847 Reading: 13 Writing: 16 Waiting:
2519
freebsd里的kqueue和linux 2.6下的epoll
兩個(gè)東西極其相似,，寫(xiě)好了一個(gè)之后,，移到別外一個(gè)平臺(tái)下，只要稍作修改就可以了,，原理是一樣,，個(gè)人認(rèn)為，從功能角度來(lái)盾kqueue比epoll靈活得多。在寫(xiě)kqueue的時(shí)候,，內(nèi)核幫你考慮好了不少東西,。但是從效率來(lái)看，從我作的壓力測(cè)試來(lái)看epoll比kqueue強(qiáng),。看看我的實(shí)驗(yàn)結(jié)果吧
客戶端： linux ,P3,，256M
,，pthread多線程程序，開(kāi)1萬(wàn)個(gè)線程,，可是實(shí)際運(yùn)行結(jié)果是,，在linux2.4上只能打開(kāi)4000多個(gè)線程的時(shí)候就報(bào)資源不足，郁悶了好久,，不知道是什么資源,，最大打開(kāi)文件數(shù)是夠了，內(nèi)存也夠（通過(guò)設(shè)置16k的?？臻g）,。后來(lái)把客戶端移到linux2.6內(nèi)核下，很快開(kāi)出1萬(wàn)個(gè)線程來(lái)了,。
epoll服務(wù)器端：P3,，256M，在一萬(wàn)個(gè)并發(fā)線程下,，面不改色,，有條不紊地處理著數(shù)據(jù)，并發(fā)數(shù)能達(dá)到8000個(gè)連接,。
kqueue 服務(wù)器端：結(jié)果比較失望,，在只能一條隊(duì)列的情況下，并發(fā)數(shù)只能到2000,，然后在客戶端的讀取數(shù)據(jù)時(shí)就會(huì)出現(xiàn)'connect
reset by
peer'的錯(cuò)誤,。后來(lái)改用了兩條隊(duì)列，一條用來(lái)接收新連接,，一條用來(lái)處理原有的連接,。在這種情況下，并發(fā)數(shù)也只能到3000,，然后又會(huì)陸陸續(xù)續(xù)出現(xiàn)連接的錯(cuò)誤,。
Nginx優(yōu)化use參數(shù)epoll,kqueue,rtsig,eventport,poll和select的區(qū)別
參考：
http://wiki./NginxOptimizations
Event Models Nginx supports the following methods of treating the
connections, which can be assigned by the use directive:
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.
