The pipeline expire tag is awesome, because it allows me to organize expiration time based on url name spaces. It does a great job even for my mini portal and blog demo. Not only the app server is not hit for an hour, but the browser will not even hit the web server until the expiration time has elapsed or you hit refresh. I've added some documentation to the Performance doc and it is show cased in one of the webserviceproxy demos:
http://xml.apache.org/cocoon/performancetips.html http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/webservicep roxy/cocoonhive/sitemap.xmap?rev=HEAD&content-type=text/vnd.viewcvs-markup So the expire tag has a double benefit. First it lightens the load on the app server, because the web server caches and second it lightens the load on the web server when the the browser has read the content once. Ivelin ----- Original Message ----- From: "Steven Noels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Pier Fumagalli" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> Sent: Friday, November 01, 2002 6:36 AM Subject: Re: [important proposal] Cocoon as official Apache project > Pier Fumagalli wrote: > > > Can't you just redirect? I mean... If you have to showcase static content > > (that's where mod_cache could help), you can generate it offline, and put it > > up on daedalus as static HTML files, and forget about it... > > I believe we (Forrest/Cocoon-people) went already at much length > explaining the current publication mechanism using CVS as a deployment > mechanism of (generated HTML) is far from optimal, given CVS's > 'interesting treatment' of new directories and the headaches one > encounters when removing unlinked/old pages. > > > If you're generating dynamic content, mod_cache wouldn't help (as it's > > dynamic), and it would only make things harder... > > A lot of the content would be dynamically generated from static XML > content, i.e. documentation. Content expiry headers could set making > sure content is only expirying daily (just an idea). Still, having one > global generation mechanism (Cocoon) for the entire site will provide us > with unified treatment (look&feel, navigation) of both dynamic and > 'not-so-dynamic' content. It will be nice challenge for us Cocoonies to > set up the website so that cache expiry is transparently configured, > dependent on the nature of the pages, but it's the kind of challenges we > like, and it will be yet another great test for the > scalability/performance of our framework :-) > > > (what's "not-so-dynamic content, btw?) > > > > Or am I _waaay_ off the hook here? > > Nope - I was expecting this debate ;-) > > Do my arguments help? Or am I simply dead wrong? > > </Steven>-- > Steven Noels http://outerthought.org/ > Outerthought - Open Source, Java & XML Competence Support Center > [EMAIL PROTECTED] [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
