cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [IMP] Performance problems with TraxTransformer
Date Thu, 30 Oct 2003 02:45:48 GMT
Sylvain Wallez wrote:

> Carsten Ziegeler wrote:
>
>> 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.


Your guess is right (IIRC).


> 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.


History [1] says:

    <parameter name="use-store" value="false"/> <!-- Setting this to 
true will crash Cocoon for now! -->

What this actually mean I'm not sure and I'm happily using "use-store" 
parameter for a long time now (currently Cocoon 2.0.4 and 2.1)


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


+1. Store is checking for Serializable (again, IIRC), which should be 
enough.


> 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.


The only way to obtain validity is to get it from the store. If store is 
not present, the alternative is to *compute* validity, which involves 
XSLT parsing and results in templates object. It will be silly to 
compute validity and loose templates, that's why method returns both at 
once.

If store is used, then templates are obtainer from the store for free, 
i.e. no CPU cycles used.

...

>> 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.
>
>
> 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).


This will require XSLT parsing, if above is correct.


> - getting the validity in the transient store is clearly separated 
> from getting the TransformerHandler.


If it is in the store, then templates are too. Unless you want to make 
validities persist in persistent store (templates are not serializable) 
-- in this case it makes sense to separate them so you do not loose 
validities on server (or CLI) restart. This should speed up CLI 
processing a bit.

Vadim

[1] 
http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/webapp/WEB-INF/cocoon.xconf?annotate=1.14



Mime
View raw message