[Date Prev][Date Next]
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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support