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.
+1
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 :
https://issues.apache.org/jira/browse/DIRSERVER-959. 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
www.iktek.com
directory.apache.org
