cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject RE: Caching jx with flow (WAS: Is use-store needed when using XSLTC ?)
Date Tue, 04 Jul 2006 07:52:18 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Ard

I'm crossposting this as it seem very valuable and far from "if this is 
just basic stuff for everybody, then of course, I am wasting my time"

Personally I'm very interested on a document showing what the 
caching/performance tuning capabilities would be.

Ciao

Giacomo

On Mon, 3 Jul 2006, Ard Schrijvers wrote:

> Date: Mon, 3 Jul 2006 19:13:31 +0200
> From: Ard Schrijvers <a.schrijvers@hippo.nl>
> Reply-To: users@cocoon.apache.org
> To: users@cocoon.apache.org
> Subject: RE: Caching jx with flow  (WAS:  Is use-store needed when using XSLTC
>      ?)
> 
> Hmmm, I hoped my mails would be so clear that it is not needed anymore 
> :-) But your right, I probably should, but it takes a lot of time and 
> effort to write it down really well....
>
> Anyway, are there people interested in a document on cocoon caching 
> with best practice and some examples regarding:
>
> - The different strategies (noncaching, caching,
>   ecaching/eventcaching, expiring) and when to use them. Appending
>   some use-cases like "how to cache untill 0:00 hours exactly" , and
>   "how to cache an external rss feed properly"
>
> - How to configure your stores properly "important for keeping you
>   cache clean"
>
> - Some tools to measure performance and caching
>
> - How to cache your jx templates.
>
> - The "watch out's" in configuring your components (for example in
>   your TraxTransformer setting
>   <use-request-parameters>true</use-request-parameters> can easily
>   bring your cocoon app down when a crawler comes by )
>
> - Which tools can help me finding the flaws (solex/tcpmon/charles(last
>   one not free) )
>
> Above is more or less configuration and examples. Below might be the 
> some more advanced topics
>
> - When writing your own cacheable component what to keep in mind (you
>   can easile makes things 100% cached while regenerating them would be
>   faster)
>
> - How does the cocoon cache mechanism work
>   (http://cocoon.zones.apache.org/daisy/documentation/writing/690.html)
>
> - and probably all the other things that come to mind
>
>
> But, I am not sure how much is already out there in documentation 
> (probably there is quite a lot, but it is scattered around, outdated, 
> and it is of course in a wiki form which is basically the equivalent 
> of "cant find the $%#$%@$%@ thing" ), and I am willing to make one 
> solid "best-practice-regarding-performance", but before that, I want 
> to know if there is interest in it. It will cost me many (probably of 
> my sparetime) hours to complete this, and I don't bother, but if this 
> is just basic stuff for everybody, then of course, I am wasting my 
> time.
>
> Regards Ard
>
>
>>
>>
>> Hi Ard,
>>
>> it might be a good idea to post your knowledge about caching
>> JXtemplate to the cocoon wiki so that other people can find
>> it there instead of on the mailinglist.
>>
>> WDYT?
>>
>> Regards,
>>
>> Reijn
>>
>> Ard Schrijvers wrote:
>>> Again, and now really in a new thread...!
>>>
>>>
>>> "I am not familiar with xsp (anymore). I use jx all the
>> time (with flow). It is by default not cached, though you can
>> arrange this via flow.
>>>
>>> How do you do this (cache) in flow?"
>>>
>>>
>>> I have changed the name of this thread since this part
>> drifts away from the inital subject. Probably known by lots
>> of users of jx is that the
>> org.apache.cocoon.generation.JXTemplateGenerator by default
>> is not cacheable. This is because lots of logic the
>> components setup is not aware of might be present in the the
>> file that is generated by the JXTemplateGenerator (the setup
>> of a component must be able to return the cachekey that is
>> processed in the pipeline cachekey AND the validity). Suppose
>> you are doing some date functions in your jx, computing the
>> current week. This can never be cached because the pipeline
>> key or validity has no dependence on what happens during the
>> generation of the jx file.
>>>
>>> But, since we often know where our specific jx depends on,
>> you can make it being cached.
>>>
>>> So, when you are in your flow function you define your
>> cachekey for the jx, and the valdity type:
>>>
>>> var ck='KEY-';
>>> var params={'cacheValidity': NOPValidity.SHARED_INSTANCE};
>>>
>>> // NOPValidity merely means something like: assume I am
>> always valid. You can equally well define an expires validity
>> if it is only valid for some time, or an eventValidity, or a
>> timeStampValdity or...that is about it I think
>>>
>>> now, to var ck you append the things that is depends on
>> (like a request parameter, current week number, etc)
>>>
>>> you add it to params:
>>>
>>> params['ck']=ck;
>>>
>>> and go back to the sitemap with
>>>
>>> cocoon.sendPage(foo, params);
>>>
>>> You have the matcher
>>>
>>> <map:match pattern="foo">
>>> 	<map:generate type="jx" src="bar.xml">
>>>
>>> and bar.xml starts with:
>>>
>>> <some-element jx:cache-key="${ck}"
>> jx:cache-validity="${cacheValidity}"
>>>
>>> Now, your JXTemplateGenerator is cached.
>>>
>>> Since we had to repeat this pattern many many times
>> (sitemap --> flow --> sitemap --> jx ) we have extended the
>> JXTemplateGenerator, where you can very easily make your jx
>> cacheable. (you just generate it, and everything it depends
>> on is added to it with map:parameter)...
>>>
>>> So for example, I have a jx depending on session and date
>> and request-param, then
>>>
>>> <map:generate src="bar.xml" type="jx" >
>>> 	<map:parameter name="foo" value="{session-attr:name}"/>
>>> 	<map:parameter name="path" value="{request-param:path}"/>
>>> 	<map:parameter name="depth" value="{date:yyyyMMdd}"/>
>>> </map:generate>
>>>
>>> Now, the cached jx would depend on these three parameters.
>> Very easy to use, and less error prone than the flow part.
>>>
>>> If somebody is interested in the code I will hear
>>>
>>> ps it is not written by me so it might be in cocoon trunk
>> already but I dont think so
>>>
>>> Regards Ard
>>>
>>
>> --
>> Met vriendelijke groet,
>> Kind regards,
>>
>> Jeroen Reijn
>>
>> Hippo
>>
>> Oosteinde 11
>> 1017WT Amsterdam
>> The Netherlands
>> Tel  +31 (0)20 5224466
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEqh40LNdJvZjjVZARAlvHAJoDlJrKqEu17G4DeYylPr6hJ24FDgCg0RGm
ZWUnyF116cmQu5eutWE52OU=
=0ULQ
-----END PGP SIGNATURE-----

Mime
View raw message