directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [ApacheDS] Bind performance
Date Mon, 17 Jul 2006 11:58:17 GMT
Hi Alex,

geat work !

I've studied some of the results early this morning, and I found that we
spend a lot of time in at least two parts :
 - LockableAttributesImpl where we allocate two HashMap to store
informations on Id and UPId
 - Invocation

I have rewrote the LockableAttributesImpl class this week-end to improve
serialization, and I removed one of those HashMap. The new class is now
around two times faster without loss of functionnality. We can have some
noticable improvment of the server if we use it, I think (but may be not
much than a few percents)

We talked about the invocation stack last week - it is used to avoid
recursion if we use trigger -, and we may think of a better way to deal with
this problem in a 1.1 or 2.0 version.

Btw, implementing a home-made serialization could improve a little bit the
server, but we might better declare LockableAttributesImpl to implement
Externalizable instead of Serializable, gaining more speed. We can also go a
little but farther and write our own serialization service without passing
through all the Serialization stack, avoiding a lot of intrsopection and
control. I still have to check if this is possible.

Lunch time over, back to work ;)


On 7/17/06, Alex Karasulu <> wrote:
> Hi all,
> Real World Tests
> ----------------
> Over the weekend I ran a few benchmarks to first get a baseline for
> ApacheDS performance.  I used a canned benchmark (job) from SLAMD for
> authentications.
> This test is more real world than doing just a bind operation.  This
> test does a bind, search for some stuff, then an unbind.  Here are the
> results of this test:
> We've got a lot of room for improvement but it's not really that bad for
> a Java based server.
> Stress Testing for Optimization
> -------------------------------
> I realized that I want to isolate specific pathways in the server not so
> much for real world tests but to be able to control the inputs when
> profiling the server.
> I really wanted to dissect the Bind operation for starters.  To do so I
> wrote my own SLAMD job class.  This was pretty neat.  I have to give the
> SLAMD developers credit. IT WORKS! I should have used this tool before.
> Anyway my new slamd test which opens a new connection then does a bind
> after bind etc is here:
> These results are summarized here even though you can sift through slamd
> to find them:
> The a YourKit CPU snapshot with full profiling against this test is here:
> Alex

Emmanuel L├ęcharny

View raw message