--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.

--Quanah

-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Rob Tanner 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?

Hard to say with just that info. If your indexes are configured to match the search filters you're using, and the cache is hot, there's not a lot else to do. It's impossible to guess what is slowing things down without knowing more about your setup.

Are you using syslog, is it at a particularly verbose level, is it logging synchronously or asynchronously? What does "top" show while a search is in progress, high CPU usage or high I/O wait? Or nothing but idle time?