Hello,
first of, thanks for the feedback and yes, I'm aware of the alternatives
to plain files and all the rest. As Hugh Sasse aptly noted, I was just
asking for this specific comparison to do some design decisions, thanks
for spotting my real question. ;P
Douglas Gray Stephens wrote:
>
>At 15:46 (GMT+0900) on 23-January-2003, Christian Balzer wrote:
> > With LDAP one is looking at the overhead to establish a TCP connection to
> > a remote system, but the database queries are of course a lot faster than
> > lsearch (at least after a certain DB size).
>
>A few extra items to put into the melting pot:
> 1. You could run the LDAP server on the localhost, and so avoid any
> of the network latency
>
Indeed. But then I also could use one of the other local DB options,
which might even be faster than a local LDAP server. I already have
a quite developed and sizable system with a combination of central
DB/LDAP servers and (exported to the local MX/SMTP boxes) plain files.
My design decision has been made to not use local LDAP servers for a
number of reasons, mostly the ability to scale DB and MAIL boxes
independently and security issues (if I'm ever forced to offer CRAM-MD5
authentication I better limit the exposure points of clear text passwords
to as few locations as possible).
And I'm equally committed to use LDAP for all places where it makes
sense, which right now is mail-routing (addresses), mailbox locations
and passwords (POP3). I'm sure that for example the list of <1000
virtual domains will always be faster in a plain file, alas for the sake
of uniformity I might move that to LDAP one day, too. The thing I'm
really trying to figure out here is at what point does it become a clear
benefit instead of a slowdown to go the full LDAP route.
> 2. LDAP has the ability to keep connection(s) open, so once there
> would be a one time hit on estabilishing the connection(s), but
> once the connections are in place there should be few overheads.
> Of course this depends on the way that emim talks to LDAP.
Yes, keepalive stuff would be very beneficial, but I have to claim
ignorance as to how Exim handles this now. It seems though that it
doesn't, at least not with 3.3x and OpenLDAP1 servers.
> 3. The LDAP server performance will depend on what indices are
> available.
>
Naturally and I'll make sure to tune things there further in the future
if needed, the current DB and scheme are pretty much optimal for the
task at hand.
>I believe that with LDAP, exim will establish a connection to the ldap
>server during a message delivery, and keeps that session open, so that
>all ldapsearches go down the same connection. Hence if you have 20
>lookups, 19 of those will not involve the overhead of setting up the
>LDAP connection.
>
This is something I would really need confirmed. Note that of the 20
lookups only 1-2 would be for the real routing, the others would involve
decisions on whether use a certain transport/ACL/RBL/local blacklist for
a specific recipient or not. Lookups happening at all times of the message
reception/delivery process, if they really all go thru the same session,
my decision would be easy.
Thanks again for all the feedback,
Christian Balzer
--
Christian Balzer Network Engineer Engineering
chibi@??? Global OnLine Japan/Exodus Communications K.K.
http://www.gol.com/
