Quanah Gibson-Mount wrote:
--On Thursday, October 05, 2006 11:58 AM -0700 Rob Tanner rtanner@linfield.edu wrote:
Hi,
I'm replacing an old Netscape server running on a 296 MHz dual processor Solaris 5.7 (sun4u sparc) box with OpenLDAP 2.3.27 running on a single 2.4GHz processor Intel box running Fedora Core 4. I have duplicated one of my hierarchies -- approx 9000 entries. There is an index on an attribute called deptaffiliationcodes (on both systems) which I'm using as a search filter to make sure everything is working. Dumping the results to /dev/null, a search on the Netscape server takes typically 35 milliseconds to complete. The exact same search on the OpenLDAP server takes between 2.5 to 3.5 seconds. And that's way too slow for me to put the OpenLDAP server into production.
I am using the bdb backend and the example DB_CONFIG file which sets the cache size to 268435456 bytes, which is bigger than the actual size of dn2id.bdb and id2entry.bdb combined (about 16Mb). What other factors can affect performance?
entrycache and idlcachesize are other things to look at. On Linux, I'd advise using something other than the default glibc allocator as well, it sucks. I've been using hoard, but I have 64 bit systems as well.
Actually I think the glibc allocator is pretty good, for single-processor systems. How well it performs for multi-processors is a different story, true.