[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Comparing OpenLDAP on Linux 2.6/Sol 10 [ was Re: Berkeley DB versions ]

On Fri, 13 Jan 2006 10:51:32 -0800
Quanah Gibson-Mount <quanah@stanford.edu> wrote:

> This really says nothing about how the system performs as an LDAP server. 
> This simply shows that Solaris 10 x86 completes a single LDAP search 
> faster.  Since LDAP servers by nature process and return results on many 
> connections at once, it is much more valuable to have the results from that 
> type of test.  

I understand that, I'm using the test to get a rough idea. 

Before, I ran 10 ldapsearches of the entire DB in parallel -- is that a more
reasonable test?

> Again, I suggest getting some performance numbers from a 
> utility like SLAMD.  And I'm certainly not saying that Solaris 10 x86 won't 
> be faster there as well, because it is entirely possible it could be.  And 
> of course, only tests against identical hardware and slapd/BDB 
> configuration really count for much too.  Even if the Linux box is supposed 
> to be faster.

Well, my original tests were on the same machine. Now, when I run 10 searches
I average about 16-17 seconds per test on the older Sol10 machine, and about
a minute per test on the newer linux machine. 

Is this not a reasonable test? Do I not get a good rough estimate with this
test? If I use OLD for directory service on Unix, I'll need good response on
delivering all my users entries when getpwent() is called, right?

> There are also matters of database and slapd tuning.  I of course assume 
> you are using a supported backend (bdb or hdb).  Standard questions include:
> Do you have a DB_CONFIG file, which a properly configured cachesize?

Here's my DB_CONFIG:

	set_cachesize   0       268435456       1
	set_lg_regionmax        1048576
	set_lg_max              10485760
	set_lg_bsize            2097152
	set_flags               DB_LOG_AUTOREMOVE

> Have you separated the BDB log files to a separate disk or a similar 
> configuration where the DB writes to not conflict with BDB logging?

No, but the majority of my use will be LDAP reads, so I'm not so 
worried about that.

> Have you tuned the BDB log file bits?


Do you think either of these would even out the tests?

> I suggest reading 
> <http://www.stanford.edu/services/directory/openldap/configuration/bdb-config.html>.
> slapd:
> Have you configured the entry cachesize?
> Have you configured the idlcachesize?
> Do you have a loglevel set (the default is 256)?  If you do, and are 
> logging to syslog, are you using synchronous or asynchronous logging?
> How many threads do you have configured (I run at 8)?

cachesize               100000
idlcachesize            300000
threads                 8

> Generally for benchmarking, I suggest putting a loglevel of 0, so that 
> syslog is not involved at all.

I had a loglevel of 256 spitting to stdout, but changing it to 0 has no noticable

As far as setting up slamd, at this point I'd need more convincing that it 
would be worthwhile to continue testing before I spend more time doing so, 
such as an obvious oversight in configuration that favors Solaris/causes
problems on Linux or new tweaks in OLD like the nanosleep fix.

I'm basically ready to go live, and while I'd love to be able to drop an 
OS platform to support, at some point I have to just make my decision and
go on.