On 4 Feb 2002, Steve Willer wrote: > > > > AxNoCache On ? > > > > That's acceptible for this particular site. Not for some of the others > > we host or we need YA hardware upgrade. > > I suppose I'd have to reframe from putting banners in the same document as > > the content, which is exactly the opposite of the directions the advertiser > > market is taking. > > This is fixable by having your final-step XSL use document() to suck in > the banner content (call it banner.xml). > > The only problem is that AxKit is rather inflexible with caching and > with subrequests. If you could cache just the first few processing > steps, rather than an all-or-nothing deal, that would be very nice.
A while back, we had this discussion. I now see the benefit of different cache stages, BUT - I still am very worried about the performance loss of all those evalutations: 1) To cache or not to cache? 2) Dir structure and subsequent IO for cache stages 3) Since you opened the can of worms, people will want dynamic caching, ie: "Stage x writes <axkit:cache value="On"/> for stage y", for instance to allow cached db queries. It will be a large project, but to move from PHP to AxKit on the frontend, would require AxKit to serve appr. 2 million page views a month, on a machine with 1 Gig of memory and stay below an average load of 20%. That's what php is doing now. So - first I'll look at Robin's suggestion and then I'd opt for a standardized cache stages implementation, where you could opt to compile it in or not. For my purposes, I would only need a pre-send-to-browser stage. The other things descibed below, do not change depending on the visitor, but depending on actions taken by the CMS. But that's of course purely because we don't serve shopping carts or other visitor dependable data. An AXKit forum would be nice :->, but you'd need a solid XML database, not a database that can 'work with XML'. > Also, if AxKit supports subrequest-called XSP pages, then that would > also be very nice. If you had both, then you could have: > > (page).xml, which does a bit of work and generally isn't cached > (page).xsl, which just builds up the page and generall doesn't cache > root.xsl, which isn't cached, but uses document() to bring in: > menu.xml, which is XSP and is cached > leftnav.xml, which is XSP and is cached > shopcartnav.xml, which is XSP and is *not* cached > > ...for example. > > I've been experimenting with building a page-building engine, and I > realized the caching is most naturally viewed as a "stylesheet engine", > just like XSP and XSLT. The "cache-save" engine would read a global > per-page flag to determine whether it should cache or not, and any step > before that engine could set that flag to set the policy. > > > Best regards, Melvyn Sopacua WebMaster IDG.nl _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If it applies, where it applies - this email is a personal contribution and does not reflect the views of my employer IDG.nl. \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
