On 4 Feb 2002, Steve Willer wrote:
> On Mon, 2002-02-04 at 14:34, Melvyn Sopacua wrote:
> > 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.
>
> 1) This is an easy one: in the thing I'm playing with, the default is
> "no", even if there is a cache-load and cache-save engine configured in
> the pipeline. One of the pieces of code being executed in one of the
> steps (XSP, Embperl, what have you) would have to essentially set a
> global variable that says "please cache me, and use a time-to-live value
> of 15 minutes". As a result, the "cache or not to cache" code would say
> something like:
> next if not session_param("pb_cacheme");
Ok, seems fast enough.
>
> 2) I'm currently thinking I'd have a pipeline spec that looks something
> like this (format here is "step_id engine_name href extraparams"):
>
> 1 engine embperl _start.exml|SKIP
> 2 clear-pipeline
> 3 cache-load (hostname)/(request_uri)/(cookies)/ skipto=6
> 4 engine xsp
> 5 cache-save (hostname)/(request_uri)/(cookies)/ (pb_cacheme) (pb_ttl)
> 6 done-if-subrequest
> 7 engine xslt (base).xsl|SKIP
> 8 engine xslt _directory.xsl|SKIP
> 9 engine xslt /kernel/_root_css(csslevel).xsl|/kernel/_root.xsl|SKIP
> 10 postprocess
>
> The second argument in the cache-load and cache-save parameters is the
> Big Ugly String to be used for the cache key. You can just MD5 it or
> whatever to build a more or less unique key. The work involved in this
> is one regular expression to convert words in parens into session
> values, an extra bit to build a cachekey, and a stat() call.
So you would stick the cache in one dir, for all stages. With over 10.000
articles, of which at any point in time, 10% is considered current (don't
you just hate, 'relevant articles'), this would generate a cluttered dir
in no time.
> 3) I don't know what that would do.
Well, sumfin like:
$numrows=db->query($sql);
if($numrows == $cached_numrows)
{
$doc->createElement('cache', 'axkit', params);
return 1;
}
else
{
...
}
> One remark: The caching mechanism I had in mind was specifically
> targeted at supporting HTML::Mason-type caching, where you might have a
> page that has 5 "panels" in it, 3 of which are cached to various
> degrees. This requires that you have caching of the XSP result, but not
> the stuff afterwards. If you want to cache an entire page, lock stock
> and barrel, definitely just stick Squid in front of the web server.
Yes, but we can't. We use the timestamp, so you could cache 1 second,
but ideally we should use a true random number.
> > An AXKit forum would be nice :->, but you'd need a solid XML database, not
> > a database that can 'work with XML'.
>
> Why? Maybe this is one of those larger issues that spawn off large
> articles on xml.com, but it seems to me that a forum message is just a
> record with a bunch of fields in it,
Yes, and a thread is a query, sharing one record id. Or an XPath query,
using 1 id.
> which would turn into an XML
> container tag with a bunch of child tags only one level deep.
Relating to, userdata.
> There's no
> reason you couldn't just fetch all rows from an SQL db as an array of
> hashrefs, and automagically convert that to a shallow XML tree....which
> TaglibHelper lets you do, coincidentally.
Yes, you could. But searching becomes much harder, you need to be
XML-aware in the body and title, before inserting to the db. Things like
bbcode and JS escaping becomes a whole new dimension, and you're still
using SQL rather than XPath, to select nodes.
Ideally - a database, would be 1 large, compressed XML document, and the
database engine, would be aware of values, vs elements, etc.
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]
