cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [IMP] Performance problems with TraxTransformer
Date Wed, 29 Oct 2003 07:29:58 GMT
Carsten Ziegeler wrote:

>While debugging/profiling a very big application for our customer I found out that the
current implementation of the TraxTransformer is slowing down caching!
>Why? Well, the caching algorithm asks every sitemap component if the cached content is
still valid. The TraxTransformer answers this question by looking if the stylesheet has changed
since the last use (time stamp comparison).
>So far so good, but you can have imports/includes in your xslt, so the TraxTransformer
checks them as well - and this is done by "parsing" the xslt and looking at all includes/imports.
This parsing is done, even when the content is fetched out of the cache. 
>Due to this mechanism, each stylesheet is parsed on every request (if cached content is
used or not) which is in most cases unnecessary. As we didn't use the "use-store" parameter
of the xslt transformer this is a real performance problem!

Is the reparsing always occuring, even if when "use-store" is "true"? I 
guess not.

This was discussed a while ago, and we have here the combination of two 

why in hell is use-store to false??? IIRC, it was fist set to true 
because the transient store was actually not transient and tried to 
serialize compiled XSLTs in the persistant store, which failed because 
these objects are not serializable.

Let's switch it to true an ensure the transient store is really transient.

This component's design is intrinsically bad from a cache perspective: 
the only way to access validity is through 
getTransformerHandlerAndValidity which always creates the 
TransformerHandler even if we don't use it. Combine this with 
use-store=false, and we end up reparsing the XSL at each call.

>As the parsing is very time consuming, delivering a cached content is still "slow". We
had figures, where a cached content took 1.5 sec (and producing it from scratch took 1.8 sec).
>With the recent changes we are down below 100ms for delivering the cached content! I added
a "check-includes" configuration to the TraxTransformer. If you set it to "false" imported
stylesheet are not checked for changes for the caching, but you really feel the performance
>So, you loose a little bit comfort but gain a lot of performance improvements. And if
you use it only for production, it shouldn't be a problem anyway. (The default is "as-is")

This way of solving the problem is hacky as it forces to choose between 
speed and auto-reload and will often lead people to either not 
understand why their changes are not taken into account or lead them to 
choose the "secure" way by setting auto-releoad to false.

We must refactor the XSLTProcessor so that:
- it returns a MultiSourceValidity if needed (see in o.a.c.c.source.impl 
in scratchpad).
- getting the validity in the transient store is clearly separated from 
getting the TransformerHandler.

>PS: The new feature will be released with 2.1.3 in approx. two weeks.

If you need the optimisation quickly for your customer, please make a 
different class or keep it private until we do the clean refactoring.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message