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

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

--On Friday, January 13, 2006 3:19 PM -0500 "James F. Hranicky" <jfh@cise.ufl.edu> wrote:

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?

No, not really. You are not exercising your server as an LDAP server in any of these tests.

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,

If your system is dumping the entire DB on that call, I suppose. My systems that look to my Directory servers for /etc/passwd information, however, look up the individual users record, not the entire DB.

There are also matters of database and slapd tuning.  I of course assume
you are using a supported backend (bdb or hdb).  Standard questions

Do you have a DB_CONFIG file, which a properly configured cachesize?

I cannot comment on your settings, really, since they depend on the resources available in your environment, and I have no access to your environment.

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?

Your above DB_CONFIG says differently (set_lg_regionmax, set_lg_max, set_lg_bsize are all set).

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

Only write tests, really. Except the set_cachesize one, of course, which could affect tests.

I suggest reading

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

Again, unable to comment on the entry cachesize and idlcachesize settings much without being able to look at your system.

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

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

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.

Whatever suits you best. I just think the testing you are doing so far doesn't really indicate anything substantive.


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