下图对比了poll select
epoll和kqueue的性能。select和poll是一个级别的,epoll和kqueue是一个级别的,相差不多。epoll用在linux上,kqueue用在bsd上,不能物理上共存。如果你的服务器cpu较好,linux内核新,可考虑用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的某个机器(centos5.3,e7300)的nginx从默认的没有use设置改为use epoll后实际情况 load
average: 0.14, 0.21, 0.26,负载似乎减少了0.1,可能并发请求量不大,暂时没看出有多大效果 :
Active connections: 2548 server accepts handled reques
ts 35279765 35279765 59264847 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./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.