Re: >1024 connections in slapd / select->poll

[Howard Chu <hyc@symas.com>]

Volker.Lendecke@SerNet.DE wrote:

> On Mon, Nov 15, 2004 at 02:47:34PM -0800, Howard Chu wrote:
>  
>
> > lists around. But on a heavily loaded server with thousands of active 
> > sessions, the fact is that your list of interesting descriptors is not 
> > static. Ultimately the server must iterate across all the thousands of 
> > descriptors, because the majority of them are probably active, and the 
> > server must insert and delete descriptors from the list continuously, 
> > because client sessions tend to come and go continually.
> >    
>
> All true, but the argument I think is that epoll has no inherent limits, and is
> optimal for many idle connections. With thousands of active connections I think
> a central select/poll/epoll/whatever is broken anyway. Only a SMP machine with
> a descriptor-passing architecture might help here.
Well if you're feeling brave, I've just completed a patch in CVS HEAD 
supporting epoll. I haven't tried testing it with a massive number of 
connections yet, but the code now passes the regular test suite. It 
should be simple enough to add kqueue support as well now (I would have 
begun that but I don't have BSD installed anywhere at the moment). 
Regular poll can easily be added if you want, but there's really no 
reason to. Solaris /dev/poll is a bit more awkward.

My initial short tests with ~20 clients shows that slapd with epoll is 
slightly slower than select. This is to be expected, as the overhead 
from setting up the event records is much higher (one system call per 
descriptor). As I noted before, if you have a mix of mostly short-lived 
connections, there's no gain here.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support