cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon Performance Analysis
Date Sat, 13 May 2000 00:32:34 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message