Cocoon Performance Analysis

[Jeff Morrill <jm...@pointnclick.com>]

Hi All,

We are using Cocoon 1.7.x under Apache/Jrun on Linux.  We are using
JDBC to generate the data, XSP to generate a document, and XSLT to
"style" the document.

We have been analyzing the apparently poor performance of this setup.  
Below I include some analysis and some questions which might be of
general interest.

One of the larger pages gets generated in an average of about 1200 
milliseconds, yielding about 20K of HTML.  Here is a breakdown of 
that, made by running Cocoon from a command line and thus outside
of Apache/Jserv.

300 milliseconds running XSPProcessor
650 milliseconds running XSLTProcessor
250 milliseconds running HTMLFormatter

The time spent in the XSPProcessor is mostly spent inside JDBC
(250 milliseconds).  We are working on this number, but obviously 
it is outside the scope of this group.

The time spent in XSLTProcessor is a different story.  It has to do with
the xml-stylesheet processing instruction that comes out of XSP:
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl"?>
This apparently causes a new StylesheetRoot to get generated for
EVERY page hit.  This is responsible for about 300 milliseconds in
the XSLTProcessor.  It seems to me that this work
is unnecessary.  Is there some processing instruction that can be
used to cause the StylesheetRoot to get cached?  Is the caching
strategy for this object implemented in Cocoon or Xalan?

(The problem does not go away by eliminating the dynamic XML
and feeding static XML into the XSLTProcessor.)

The time spent in the HTMLFormatter also seems exhorbitant.  We
looked at a couple of other HTML Formatters and found they run
in about 1/4 the time, or less.  We also noticed that those formatters
did not do a very good job in certain tricky cases.  So you might
expect the more thorough formatter to take longer.  On the other
hand, we can easily avoid the tricky cases, and so we don't need
the more thorough formatter.  Are there any flags for speeding it
up, or for substituting our own?

Thanks,

jeff morrill
jmorrill@pointnclick.com

Re: Cocoon Performance Analysis

[Stefano Mazzocchi <st...@apache.org>]

Jeff Morrill wrote:
> 
> Hi All,
> 
> We are using Cocoon 1.7.x under Apache/Jrun on Linux.  We are using
> JDBC to generate the data, XSP to generate a document, and XSLT to
> "style" the document.
> 
> We have been analyzing the apparently poor performance of this setup.

The poor performance is not apparent, it's evident.

> Below I include some analysis and some questions which might be of
> general interest.
> 
> One of the larger pages gets generated in an average of about 1200
> milliseconds, yielding about 20K of HTML.  Here is a breakdown of
> that, made by running Cocoon from a command line and thus outside
> of Apache/Jserv.
> 
> 300 milliseconds running XSPProcessor
> 650 milliseconds running XSLTProcessor
> 250 milliseconds running HTMLFormatter
> 
> The time spent in the XSPProcessor is mostly spent inside JDBC
> (250 milliseconds).  We are working on this number, but obviously
> it is outside the scope of this group.

Yes. Also shows that the time spent in XSP generation is 50 millis,
which is still too much.
 
> The time spent in XSLTProcessor is a different story.  It has to do with
> the xml-stylesheet processing instruction that comes out of XSP:
> <?xml-stylesheet href="mystylesheet.xsl" type="text/xsl"?>
> This apparently causes a new StylesheetRoot to get generated for
> EVERY page hit.  This is responsible for about 300 milliseconds in
> the XSLTProcessor.  It seems to me that this work
> is unnecessary.  

Yes, we are totally aware of this, but instead of fixing something for
speed when we are ready to abandon this codebase, we'd rather spend time
writing a better underlying architecture for Cocoon2 (which is already
in place and much better since it will use pools of compiled
stylesheets, thus removing this overhead)

> Is there some processing instruction that can be
> used to cause the StylesheetRoot to get cached?  Is the caching
> strategy for this object implemented in Cocoon or Xalan?

No, the caching strategy of compiled stylesheets is not implemented in
Cocoon1, but will be in Cocoon2.
 
> (The problem does not go away by eliminating the dynamic XML
> and feeding static XML into the XSLTProcessor.)

I know, this is the time taken by Xalan to compile the stylesheet into
its own in-memory representation and should be done only once for each
stylesheet reloading.
 
> The time spent in the HTMLFormatter also seems exhorbitant.  

The Xerces group are already aware of this. Since Xalan 1.1 will use the
Xerces serializers and Xalan serializers are about 4 times faster, I
expect much speed improvement coming from this directly.

> We
> looked at a couple of other HTML Formatters and found they run
> in about 1/4 the time, or less.  

Yes, we are aware of this.

> We also noticed that those formatters
> did not do a very good job in certain tricky cases.  So you might
> expect the more thorough formatter to take longer.  On the other
> hand, we can easily avoid the tricky cases, and so we don't need
> the more thorough formatter.  Are there any flags for speeding it
> up, or for substituting our own?

No hooks for speading up that I know of, but by simply adding your own
formatter to the cocoon.properties file allows you to plugin any class
that implements the formatter interface.

As a general rule, we don't want to spent time optimizing performance
before a stable architecture is in place, otherwise, we end up wasting
time.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------