[Date Prev][Date Next]
Re: >1024 connections in slapd / select->poll
Igor Brezac wrote:
Been there... I haven't been motivated to investigate poll() because it
really doesn't offer any scaling benefits vs select(). As for /dev/poll
and epoll() - they sound nice, but I don't want to get too bogged down
in OS-specific special cases. I guess a decent abstraction layer above
it would be OK, but I definitely don't want to see a lot of #ifdef
HAVE_DEVPOLL/HAVE_EPOLL junk littered all over daemon.c.
On Sun, 14 Nov 2004 Volker.Lendecke@SerNet.DE wrote:
On Sun, Nov 14, 2004 at 08:31:49AM -0500, Kurt D. Zeilenga wrote:
Yes, moving to poll() (and alternatives) is a TODO list item.
We're been moving slow because of a few unknowns, namely
interaction with threads and performance. Positive operational
experience using poll() here would help move things forward.
poll tends to suffer from thousands of connections. But the move to
be an a bit larger patch. There you can not loop over all fd's and
see if any
of those is readable or writable, epoll gives you the descriptors on
something has happened. To support huge numbers of connections where
them are idle it might be better anyway as the overhead to scan all
become too large.
/dev/poll on Solaris would improve things, but like epoll it is not
This might help: http://www.kegel.com/c10k.html
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support