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

[Howard Chu <hyc@symas.com>]

David Boreham wrote:

> > > What's the purpose of having that degree of concurrency ?
> >
> >
> > In fact, we've currently got the MTA (it's called simta) set to limit 
> > itself to 250 inbound SMTP connections.  We monitor the SMTP 
> > interface (and the LDAP interface) to ensure that it remains 
> > responsive.  Our customer expectation is that when email is sent, it 
> > will arrive at the UMich recipients mailbox within seconds.  In 
> > short, the concurrency reflects how our users send & receive email.
>
>
> Hmm...so, e-mails can be quite large, therefore it seems reasonable
> to have a large number of concurrently active SMTP connections:
> each client might be limping along sending a message slowly, etc.
>
> However, I'm not sure I see why this implies that you need
> to keep an LDAP connection open, and one per SMTP
> session, for the duration of the message receipt or relay activity.
>
> Why wouldn't you open the LDAP connection when you need
> to look something up, and then close it again? Or better still
> use an LDAP connection pool?
> I'm having a hard time seeing why you need to perform 250
> concurrent LDAP operations. I can see why you'd need to
> perform LDAP operations at a high rate, but not why you're
> trying to do so over a huge number of concurrently open connections.

I agree, you can have a high number of concurrent operations without 
needing so many connections. But it sounds like the MTA forks a process 
per email message, and so its client library opens an LDAP session per 
message as well. Not exactly conducive to sharing/pooling resources. In 
this case I'd set up the reverse of what I outlined in a prior message; 
set up dedicated LDAP proxies (e.g. using connection pooling in 
back-ldap) for each MTA to aggregate all their traffic into a smaller 
number of connections to the real LDAP server. With a local LDAP proxy 
running over ldapi:// there'd be practically zero connection 
setup/bind/teardown overhead, so you'd be getting the maximum ops/second 
throughput.

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