On Wednesday 15 March 2006 16:58, Peter Mogensen wrote: > Hi, > > An often heard argument for LDAP is that it is optimized for many reads > and only a few writes. ... And it seems intuitively reasonable that it > should be faster than an RDBMS for such applications. > > Now... I have a lot of configuration data for many users, which I need > to query very often and write very seldom. There's not many relational > contraints in it, so I figured OpenLDAP would be better than PostgreSQL. > > But a quick test using Perl DBD::Pg and Net::LDAP shows me that this > might not be the case. In short I tried to: > 1 Insert 20000 simple objects with index on PK/DN > 2 Query 20000 objects on the indexed attribute > 3 Query 10000 objects on a non-indexed attribute > > The results was (in seconds): > > PostgreSQL (7.4.7): > > 1: 20 > 2: 10 > 3: 150 > > OpenLDAP (2.2.23) (BDB-backend): > > 1: 185 > 2: 49 > 3: - > > > I didn't bother wait for the last run. ... I was probably way over 1000. > Now it didn't surprise me that LDAP was slower for inserts, but it did > surprise me that it was 5 times slower for lookups on an indexed attribute. With single-bind many-queries, results of over 20 000 searches/second are possible (on indexed attributes) without too much tuning on reasonable (ie dual 3 GHz Xeon) hardware. So, I suspect you have missed some tuning, most likely you have no DB_CONFIG file in your database directory, or it is inadequately tuned. More information (ie slapd.conf extracts, log extracts, DB_CONFIG file etc) would help ... Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpt0HLBO95zp.pgp
Description: PGP signature