cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Performance problems with 2.1.10 using FOM JavaScript cocoon.load()
Date Tue, 06 Mar 2007 13:21:33 GMT
(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.


> 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

View raw message