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
