(Berry) A.W. van Halderen wrote:
The problem is that when upgrading to Cocoon 2.1.10 for one of our software
packages to make use of all the improvements in 2.1.10, we're hitting an
enormous performance hit. We basically see that requests which would normally
take 10ths to 100thms of microseconds now takes seconds upto a minut to
execute, where the processor is fully used.
Now basically we needed to make no modifications to our software to use 2.1.10
apart from updating dependencies. We think therefor that the bad performance
comes from some way we use Cocoon, especially some classloading issue.
I've profiles the application to some extent, and I'm seeing that the
application is in fact slow because when executing a server-side JavaScript
file, it is loading other JavaScript files (through cocoon.load()). This
loading is slow, because even though it seems to be cached, it is calling the
classloader to look-up the cache definitions of all referenced Java code.
This makes an enormous hotspot in the Jetty ContextLoader classloader, which
can return a reference to the class quite quickly, but has to give a lot of
them.
Cocoon 2.1.10 has latest version of rhino (js-1.6r5), while cocoon 2.1.9 comes
with older 1.5r4. This change probably is the cause of the issue, try comparing
behavior of these two rhino versions.
Vadim
Now the total application, accessing a single page results in a number of
execution of JavaScript files, and a JavaScript file is executed more than
once. The most important hint probably is that I've looked at the most
important JavaScript file, and I'm seeing that when executing this script more
than once that in its execution of cocoon.load()'s of other files it is
ALTERNATING fast and slow. And I really mean one time fast, then slow, then
fast, then slow... When tracing back, there is no difference in its call
stack between the two cases.
I'd really appreciate any hints at the moment where to look at, because I'm
running out of ideas where to trace the beast next.
Thanx,
\Berry
