directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [ServerEntry] Next step
Date Wed, 30 Apr 2008 11:24:14 GMT
Hi guys,

I have finished to modify the code to get the ServerEntry serialized 
into the backend. It was not really easy, but it's done. It also has 
some impact :
- I had to modify JDBM in order to be able to deserialize the entries 
(just added an accessor to a class)

A mail has been sent to Alex Boivert to see if he can provide a new 
version for this jar (we are currently using 1.0.0) and he replied that 
he will try to find some time in a very busy schedule to deliver a 
1.0.1, which will have to be deployed to a maven repo. Another coiple of 

Here is what I suggest at this point : I have created a sub-project 
(apacheds-jdbm) containing the JDBM code with almost all of the tests 
(except the performance tests), and it works pretty well. I will commit 
this code and my modification in the bigbang branch, as I have to move 
on to the next step : removing the JNDI layer.

The reason why I'm impatient to do that is that I have a 13 000 lines 
long diff pending, and I'm afraid to do some modifications on the server 
with around 100 impacted files, as it may break the currently working 

FYI, I have run some perf test on my laptop, and here are the compared 
results for 1.5.2 and bigband (as always, local test, not meaningfull, 
blah blah, for your eyes only :)

1.5.2       : 3506 random search req/s
bigbang : 4296 random search req/s

I also profiled the server and found interesting numbers :

LdapDN handling : 37.6% of the CPU (out of which around 18% can be 
squeeze when the JNDI layer will have been removed)

ServerEntry handling : 19.60% of the CPU

ASN.1 codec : 10,15%

This is 67,4% of all the consumed CPU in tasks which are difficult to 
improve (if we except the 18% we can squeeze from some useless double 
LdapDN parsing), the rest is spreaded in small methods.

A blind guess is that it will be quite challenging to gain a lot now. My 
own expectation is that we should be able to go up to 6000 searches 
req/s on my laptop, but then, we will have to check the LdapDN parsing 

It would be very cool if someone can double check the ServerEntry clone 
method to see if it's optimal, and if we can improve its code (or even 
find some bug or bad logic in it).

I was also thinking that some lazzy cloning might be enough (ie, cloning 
only the attribute container, not the attribute values themselves, as in 
many case, we are just removing attributes from the entry before 
returning it, keeping the attributes unmodified. That would save a few %)

That's it, I'm now waiting for Eris to be up and running...

thanks for your attention !

cordialement, regards,
Emmanuel L├ęcharny

View raw message