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. > > Is this expected behaviour, or should I start looking for som stupid > mistake in my test? BTW, I ran some tests over the weekend, and it seems your benchmark software (probably Net::LDAP as Howard mentioned) is the problem. I dropped the unindexed searches from 10000 to 200 (10000 searches on an unindexed attribute is just a waste of time), and made the adds conditional: [comanche:/home/bgmilne]# ./bin/ldapvspgsql; for i in `seq 1 20000`;do echo $i;done > /tmp/ldapsearch.in;time ldapsearch -LLL -x -b dc=nodomain -f /tmp/ldapsearch.in "(cn=%s)" >/dev/null; for i in `seq 1 200`;do echo $i;done > /tmp/ldapsearch.in;time ldapsearch -LLL -x -b dc=nodomain -f /tmp/ldapsearch.in "(pif=%s)" >/dev/null INDEXLOOKUP: 46 LOOKUP: 116 0.89user 0.58system 0:08.04elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2major+455minor)pagefaults 0swaps 0.02user 0.02system 2:14.29elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+458minor)pagefaults 0swaps During this run, ldapvspgsql was using about 75% CPU during the index lookup (slapd was using about 20%), ldapvspgsql used about 2% during the unindexed search and slapd more than 95%. ldapsearch used about 20% of the CPU during the indexed search with slapd at 65% and syslog at about 15%, and ldapsearch used about 0% during the unindexed search with slapd using more than 95%. So, on the indexed searches, the ldapvspgsql CPU consumption was at least one important factor in limiting performance. I can't explain why ldapsearch was slower at the unindexed search than ldapvsgpsql though ... Anyway, since the numbers for the indexed search with your script are relatively close to the numbers you got, it seems OpenLDAP is marginally (20%) faster at 8s than PostgreSQL (10s). Now, the real question is, how closely does this model your usage? In our scenario, we have about 12 client servers with multiple processes querying one LDAP server, so multiple concurrent searches is much more important to us (but, I haven't benchmarked PosgreSQL for the same use case). Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpuY4Qr1ijW2.pgp
Description: PGP signature