directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject ApacheDS performances
Date Thu, 22 Aug 2013 21:39:58 GMT
Hi guys,

thanks to Pierre Arnaud, we have conducted some tests today to check the
performances of ApacheDS in various configurations.

We used 5 computers as injectors, with 10 to 20 clients on each
computer. The server was Pierre-Arnaud laptop (Mac OSX, 8Gb, Core i7, a
pretty decent computer). The test was done with 10K entries in the
server (we could have injected more entries, but that would have
required a lot of time with boh JDBM and Mavibot).

We ran 3 tests :
- one with JDBM
- one with Mavibot
- one with OpenLDAP

We had to tune JDBM cache to get some decent performances. Mavibot was
not tuned at all, except that we set the memory to a high mevel (more
later about this). We tuned OpenLDAP config so that no log is generated.

The test was to launch a client looking 200 000 times for a random entry
(cn=user<random>) with a base of cn=user[1..10000], subtree search,
starting at a position in the DIT. Nothing really fancy here.

The results are to be taken with a pinch of salt, as we more or less
evaluated the number of request per second, a 10% margin or error is
likely to be present.

1) OpenLDAP is the fastest, with at least 26 000 search/s, and the CPU
wasn't maxed (we reached 85%). The network transfer rate was around 20Mb/s.

2) ApacheDS with Mavibot reached 20 000 search/s, with 100% CPU on the
server, and around 16.7 Mb/s transfered through the network

3) ApacheDS with JDBM reached 8 300 search/s, with 55% CPU and 6Mb/s
network transfer.

JDBM is clearly the bottleneck. But even if we were to use the CPU at
100%, we would be 30 slower than Mavibot

Mavibot has another probem : when injecting the entries, at some point,
when the allocated memory is fully used, it takes forever to add new
entries. This is due to the fact we use weakReferences, which are very
expensive to be reclaimed by the GC. We have to use a standard LRU/CLOCK
cache instead.

All in all, we have some areas in the server where we can improve the
code, by removing some useless costly computation (like the String <->
byte[] transformation of UP values, or the entry cloning, decrease the
number of useless writes we do on disk). We are going to work on that.

We need to conduct some more serious benchmarks, too, with stable
injectors and gathered results.

That's for september.

ALl that I can say is that I'm quite please by the performances we get
with Mavibot, even if we still have a lot of work to do. OpenLDAP is
still the winner, but I would be extremelly surprised if it weren't the
case - the opposite would simply have meant we have missed something in
OpenLDAP configuration ;-).

I will now leave for one week of hollidays, so just enjoy those numbers
while I enjoy the sea and the sun !

Emmanuel L├ęcharny 

View raw message