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 >> 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 >> true 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 >>>> >>>> >>>> >>>> >>>> and bar.xml starts with: >>>> >>>> >> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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