下图对比了poll select epoll和kqueue的性能。select和poll是一个级别的，epoll和kqueue是一个级别的，相差不多。epoll用在linux 上,kqueue用在bsd上,不能物理上共存。 如果你的服务器cpu较好，linux内核新，可考虑用epoll.
!!!Image resized! Click here to see original image!! !!!Original width:1018 Original height:786 Retry times:1 !!!
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的某个机器（centos5.3,e7300）的nginx从默认的没有use设置改为use epoll后实际情况 load average: 0.14, 0.21, 0.26，负载似乎减少了0.1，可能并发请求量不大，暂时没看出有多大效果 ：
Active connections: 2548
server accepts handled requests
555-5555555-5555555-55557
Reading: 13 Writing: 16 Waiting: 2519
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
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.