LDAP is very fast at retrieving data, not so foat at updating data. As a
rule, any user information that isn't updated often and isn't stateful (e.g.
number of logins, where you're updating every time a user logs in) is fair
From: "Patrick K. O'Brien" <pobrien@...>
To: "tlilley" <tlilley@...>
Cc: "Webware" <webware-discuss@...>
Subject: RE: [Webware-discuss] LDAP Anyone?
Date: Sun, 6 Jan 2002 16:55:02 -0600
Cool. Could you comment on the appropriateness of LDAP for things like a
sales & marketing application? I'm wondering how far LDAP can be extended
beyond the internal contact list. Does it really make sense to use LDAP to
keep track of external contacts for more than just an email address? Or
would it be better to keep that contact information in some other storage,
like a MySQL database?
On Mon, 7 Jan 2002, Dwayne King wrote:
> LDAP is very fast at retrieving data, not so foat at updating data. As a
> rule, any user information that isn't updated often and isn't stateful (e.g.
> number of logins, where you're updating every time a user logs in) is fair
This is a widely-held (and widely-spread) belief, but I file it under
"implementation dependant". There's nothing I've seen in the LDAP spec(s)
that hinders update speed. Now, in general, vendors are "allowed"
(encourage?) to tune their implementations for read performance, but this
does not -have- to come at the expense of write performance.
Case in point, OpenLDAP is written on top of ye olde standard DBM stuff,
so there's really no reason its update performance should pale in
comparison to anything else written around DBM.
If update performance is important to you, I suggest looking carefully at
the implementations you're likely to use, and benchmarking them under
representative loads, instead of just buying the "LDAP is read-optimized"