directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] Why was the notAliasCache added to ExceptionUtils?
Date Mon, 04 Aug 2008 10:06:19 GMT
Alex Karasulu wrote:
> I don't know why this was added instead of adding eager entry loading.  It
> was added during one of the 1.5.x iterations. 
Just before we released 1.5.1, to be clear.
>  We should get rid of this
> notAliasCache optimization here in ExceptionUtils since all
> ContextOperations will soon eagerly load the target entry if present. 
>  The
> check for aliases will not incur the overhead that this cache hopes to do
> away with.  Instead this eats more memory, more contention, and will
> actually cost more in processing time to match the DN.  This is an example
> of premature optimization becoming more of a problem then it solves.  
I won't say it's a premature optimization, but in any case, this is a 
hack. This cache was created during a performance  improvement session, 
among other improvements, in order to have good performances for 
LdapCON. So, yes, this was more a "political mov" than a technical one...
> <code snip/>
> This is totally unnecessary and a distraction.  Yeah we get some slight
> performance advantage for a few months.  Then it becomes a problem.
More than that, it's another cache, when we already have many. I have to 
admit that the idea was short sighted. What make me feel more 
uncomfortable is that I added this portion of code after having 
complained about the too many caches, and created a JIRA : Note the ironic 
sentence :

"Up to this point, it becomes to be a full mess. We have so many 
different caches, with so many different configurations, that it's 
almost impossible to know how to correctly tune the server. Moreover, we 
may have empty caches when other are heavily hit."

Yeah, I wass the one who complained about cache exponential growth and 
who added a new one...
> If we add temporary solutions then we should make sure we note it in JIRA so
> we can later go back and cleanup the workaround. 
I _think_ that I created this JIRA just in order to be sure we will 
clean the mess. The JIRA has been created on june, 5, 2007, at 11:36 am 
and the code has been committed the very same date, at 4:03pm ... So 
there is a correlation between those two actions.
>  Also having an issue that
> is required to be completed before cleaning up the no longer needed code is
> a good idea.  Like for example a "add eager loading of target entries to
> OperationContexts" could be an issue that needs to occur before the "Remove
> not alias cache in ExceptionInterceptor".
> This code (an optimization in dev cycle) though is not a case where it is at
> all warranted.  It is an example of a performance improvement that will be
> determimental to performance as the architecture shifts to accomodate these
> performance bottlenecks.  
totally true.
> This is why I fear premature optimizations.
This was certainly not a good optimization...
> Optimizations need to occur while producing release candidates before a
> major GA release, or subsequent to the GA in maintenance releases.  Instead
> of optimizing a development branch we need to shift the architecture to fix
> the problem.
The JIRA was created to be sure we review this before 2.0. But you know 
how things are : when you see low hanging fruits, you always think that 
picking them is a good idea, even if the fruits are still too young ...
> <main-point>
> As a rule we should not optimize in development releases.  Optimization
> should be left to RC releases before a GA or in maintenance releases
> afterwards.
> </main-point>
Let's do that. This is absolutely now that we are moving forward 2.0, 
and for the future releases. Performance should not become a target when 
we have a lot of serious other issues to fix. A buggy server with better 
performance is still a buggy server ...

Thanks for pointing this out, Alex !

cordialement, regards,
Emmanuel L├ęcharny

View raw message