cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [IMP] Performance problems with TraxTransformer
Date Wed, 29 Oct 2003 09:05:21 GMT
Sylvain Wallez wrote:
> 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
> bug/deficiencies:
> use-store
> ---------
> 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.
> XSLTProcessor
> -------------
> 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 difference.
> >
> >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.
> >
> >
> -1.
> If you need the optimisation quickly for your customer, please make a
> different class or keep it private until we do the clean refactoring.
Which will never happen due to time constraints ...(just a joke).

Anyway, I agree that refactoring the XSLTProcessor is a way to go and
that with useStore the problem is not that important.

BUT, then even if the content is fetched from the cache, the XSLT
Processor is "activated" for the stylesheet, which is imho a total
overkill for finding out that the main stylesheet has changed; so
I still think this option is very very useful and doesn't do any
Just make some speed comparision with and without the flag and
see if it helps you as well.


View raw message