[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: 2.2.23 vs 2.3.1alpha speed compairisons
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Armbrust, Daniel C. wrote:
> We have a java application that reads and writes terminologies from a
> server - the server part is pluggable - we have implementations that
> work against ldap and against SQL. I have been doing some testing,
> and thought that these numbers may be of interest to other folks.
>
> The numbers below are the amount of time in milliseconds that it took
> to do the operation on the terminology. The client and server
> hardware was the same for all tests.
>
> The BerkeleyDB version for openldap 2.2.23 was BerkeleyDB 4.2.52(.2)
>
> The BerkeleyDB version for openldap 2.3.1alpha was BerkeleyDB
> 4.3.17(.3)
>
> Further configuration info below.
>
> Full Read AVG
> Ldap 2.3.1alpha 5906 5750 5812 - 5822
> Ldap 2.2.23 7188 7235 8047 - 7490
> MySQL 4703 4610 4687 - 4666
>
> Full Write
> Ldap 2.3.1alpha 46484 44765 45406 - 45551
> Ldap 2.2.23 (no log) 7547 7843 7812 - 7734
> Ldap 2.2.23 (logging) 38235 45125 42797 - 42052
> MySQL 5828 6250 7156 - 6411
>
> Full Erase
> Ldap 2.3.1alpha 43000 47672 46750 - 44390
> Ldap 2.2.23 (no log) 5687 5922 6094 - 5901
> Ldap 2.2.23 (logging) 43657 46265 44703 - 44875
> MySQL 328 203 188 - 239
>
>
> (no log) means that my DB_CONFIG file looked like this:
> set_flags DB_TXN_NOSYNC
> set_flags DB_TXN_NOT_DURABLE
> set_cachesize 1 0 1
>
> (logging) means that my DB_CONFIG file looked like this:
> set_cachesize 1 0 1
>
> The DB_CONFIG file for 2.3.1alpha was:
> set_cachesize 1 0 1
> set_flags DB_LOG_AUTOREMOVE
>
>
> Performance is roughly what I would expect in comparison to MySQL -
> and I was happy to see that reads have gotten faster in the 2.3
> series. The logging issues are something else, however. Since we
> converted from ldbm to bdb - we have always disabled the logging - we
> really have no need for it. The logging certainly isn't worth the
> performance penalty - and disabling it was the only way to get
> comparable performance to what ldbm had.
I don't think your statement is correct ... you can improve performance
by tuning the logging subsystem:
http://www.openldap.org/faq/data/cache/893.html
http://www.sleepycat.com/docs/api_c/log_list.html
Since you don't include any set_lg_* entries, I assume you don't have
any in your DB_CONFIG file, in which case performance (especially for
writes) will be dismal with logging enabled.
> Does anyone know if the logging changes to the new version of
> BerkeleyDB are a bug, or a "feature"? Because having the logging
> turned on makes the performance of openldap to horrible for us to use
> for large inserts. And if they won't allow us to turn it off anymore
> - I would want to go file a bug report on it.
Well, maybe you should investigate tuning of the Berkeley DB logging
subsystem?
Regards,
Buchan
- --
Buchan Milne Senior Support Technician
Obsidian Systems http://www.obsidian.co.za
B.Eng RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGap1rJK6UGDSBKcRAkstAJ9eDDbEQHnIeRWv57EpZQrWc+b3hQCaAzDt
hc7SQYhqq6G/CkO0dZ7B8FM=
=0Vs7
-----END PGP SIGNATURE-----