[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,
right?
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
include:
DB_CONFIG:
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
<http://www.stanford.edu/services/directory/openldap/configuration/bdb-c
onfig.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
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
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.
Whatever suits you best. I just think the testing you are doing so far
doesn't really indicate anything substantive.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html