cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niels van Kampenhout <n.vankampenh...@hippo.nl>
Subject Re: Caching jx with flow (WAS: Is use-store needed when using XSLTC ?)
Date Tue, 04 Jul 2006 08:50:29 GMT
Ard,

What about a talk about Cocoon caching at the Cocoon GetTogether?

Niels



Giacomo Pati wrote:
> 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

Mime
View raw message