[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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