directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [ServerEntry] First performance tests
Date Sat, 16 Feb 2008 17:15:26 GMT
Hi guys,

now that we have removed references to Attributes into the core, I have 
run my favorite benchmark to see which kind of performance we get. This 
is of course very preliminary, and done in order to see where we have 
performance problems.

You have to keep in mind that this switch was not intended to increase 
the performance, but to improve the correctness of the server, by 
simplifying attributes manipulation (mainly attributes comparisons and 
value manipulations).

So far, the performance I got are far worst than the best performances I 
obtained with 1.5.1 : 1650 req/s compared to 4800 req/s. This is just 
one third of the previous result !

So where do we eat ms ?

Mainly in the new API, which is good (as it's not optimized at all). The 
main issue is the way we treat ObjectClasses. There are overkilling 
tasks done more than once, for instance when we are adding a new 
ObjectClass. The ancestor is computed many times, and we are creating 
far too many arrays and Lists. This has to be changed.
FYI, The ServerEntry.put( ServerAttrinute[] ) method cost 40% of the 
time. Far too much ! (The inner method addObjectClass( ObjectClass ) is 
responsible for this.

The DefaultOidRegistry.getOid( String ) is called more than 1 million 
times when doing around 2500 searches, for a global cost which represent 
33% of the server time. This has to be improved too. This is due to the 
fact that we transform the String to a lower cased string almost for 
every call, when we should deal with OIDs. As such elements should have 
been normalized very soon in the chain, this should not happen.

Last, not least, we have a lot of calls to the 
ServerEntryUtils.toServerEntry() method, which is used to transform an 
Attributes to a ServerEntry (as we are still storing Attributes in the 
backend. This is terribly costly (30% of the server time). This will 
disappear as soon as the backend will handle ServerEntry instead of 

Hopefully, we will be able to fix those points very quickly.

Remember that this is just a preliminary check, FYI.

cordialement, regards,
Emmanuel L├ęcharny

View raw message