cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathaniel Alfred" <>
Subject RE: [IMP] Performance problems with TraxTransformer
Date Wed, 29 Oct 2003 17:44:02 GMT
Checking all dependencies sounds first to be the right thing to do
but it can introduce a new performance bottleneck.  Just think of
a well structured hierarchy of stylesheets stored on a filer,
where now the cache validity check requires dozens of NFS-stat

Caching on a production server is important but there must be also
a possibility to flush the cache short of restarting the server.
May I suggest to extend the TraxTransformer configuration to 
allow specifying a touchfile whose filestamp is checked for the
validity mechanism.  

In production one can then use a global touchfiles to flush the 
cache manually whenever there might have been an update of a 
stylesheet.  If needed, a finer granularity can be obtained by
using application specific touchfiles.

If the touchfile is not specified, it defaults to the root
stylesheet - that is the effect of Carsten's current 

Cheers, Alfred.

>-----Original Message-----
>From: Carsten Ziegeler []
>Sent: Mittwoch, 29. Oktober 2003 10:05
>Subject: RE: [IMP] Performance problems with TraxTransformer
>Stefan Seifert wrote:
>> Wouldn't it be better to extend the validity mechanism?
>> When the master xslt does not change, the includes does not 
>change either.
>> It should be possible to use an extended validity object that,
>> when parsing the xslt for imports/includes is finished, stores
>> the modification date of the main xslt *and* the modification
>> dates of all (recursivly) found depended XSLT pages as well.
>> The validity check would have to check a couple of modification
>> dates, but it is not needed to parse any XSLT again if it is 
>not changed.
>> I planned the implementation of such a mechanisme some time ago,
>> but due to the lack of time i did not got very far. I hope to
>> find the time in the next days/weeks, but i cannot promise
>> anthing right now, unfortunately.
>Yes, that mechanism would work also and might be a little bit better
>from the user perspective. But of course, it makes the whole thing
>more complicated.

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company. 

View raw message