[Date Prev][Date Next]
Re: Comparing OpenLDAP on Linux 2.6/Sol 10 [ was Re: Berkeley DB versions ]
--On Friday, January 13, 2006 11:14 AM -0500 "James F. Hranicky"
On Thu, 12 Jan 2006 16:09:55 -0800
Quanah Gibson-Mount <email@example.com> wrote:
b) I've not tested Solaris 10 on the x86 platform at all, so I can't
really speak to that. However, if you were using the Linux 2.6 kernel,
the 2.6 kernel developers broke sched_yield deliberately, and OpenLDAP
2.3.17 is the first real release to address that. I suspect if you
were using 2.6 previously, you may find it to be much faster now.
Not particularly, according to a very simple test:
Sol10x86 (OLD 2.3.12):
<root@sol10:/var/tmp> # time ldapsearch -H ldapi:/// -Y EXTERNAL >
/dev/null ldapsearch -H ldapi:/// -Y EXTERNAL > /dev/null 0.73s user
0.07s system 98% cpu 0.812 total
<root@sol10:/var/tmp> # time ldapsearch -H ldap://localhost/ -x >
/dev/null ldapsearch -H ldap://localhost/ -x > /dev/null
0.66s user 0.10s system 29% cpu 2.535 total
Suse 9.3 (OLD 2.3.17):
<root@lin:~> # time ldapsearch -H ldapi:/// -Y EXTERNAL > /dev/null
ldapsearch -H ldapi:/// -Y EXTERNAL > /dev/null 0.01s user 0.00s
system 0% cpu 9.266 total
<root@lin:~> # time ldapsearch -H ldap://localhost/ -x > /dev/null
ldapsearch -H ldap://localhost/ -x > /dev/null 0.01s user 0.00s
system 0% cpu 17.118 total
Same DB version for both, but the Linux box is newer and faster.
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. 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.
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?
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?
Have you tuned the BDB log file bits?
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)?
Generally for benchmarking, I suggest putting a loglevel of 0, so that
syslog is not involved at all.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html