cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <ghow...@crosswalk.com>
Subject RE: [RT]: Calculating the cache key
Date Tue, 21 May 2002 18:04:04 GMT
I like all that -- assume it would involve fairly invasive restructuring of
the whole pipeline process, but need to go read up on the prior discussion
you mention.  

Seems like from a performance standpoint, the per-pipeline setup is best:
non-cached matches don't need to waste time checking a cache, and cached
pipelines could be optimized to assume caching behaviour.

I *really* like the external trigger/periodic system for caches.  Related to
that, how about this -

I have been looking into extending the current store/generator relationship
to allow generators to report dependencies and have the store track which
keys (however they are created) are related to which dependencies.  In the
situation where a database trigger on update/delete needs to signal cache
removal/invalidation (i favor removal in this case) the store could expose a
removeByDependency(Object obj) function and just look up the relevant keys
in its own dictionary.  The number of types of dependencies isn't too great
(in our case maybe 10).  Currently I think the store would need to iterate
over every key and match strings or compare hashes.

Carsten let me know that the store is moving to excalibur and I haven't been
able to look into whether they define anthing like this or not.  Anybody
know off hand? 



-----Original Message-----
From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
Sent: Tuesday, May 21, 2002 11:29 AM
To: cocoon-dev@xml.apache.org
Subject: Re: [RT]: Calculating the cache key


Geoff Howard wrote:

>The performance of key comparison is especially important for high traffic
>sites (like ours).  An idea I've had to decrease this importance is:
>
>An *option* to have the pipeline do asynchron cache validation - if a
cached
>item exists, use it *then* check it's validity (or cause it to be checked)
>and remove it from the store if it was expired.  This is attractive to us
>because we'll have many steps that will need to be checked (many of our
>pages will involve 5 or 6 or more generators aggregated and included) and
>the performance hit of generating and comparing all those keys is scary.
>This integrates well with the external cache validity concept that Marcelo
>Ochoa/DBPrism has been working on.
>

Geoff, this a really good use case for the need of per-pipeline choice 
of the pipeline implementation, which has been discussed some time ago :
- webapp pipelines *must* use up-to-date content (i.e. cache validity is 
always checked, or no cache is used at all)
- content publication pipelines don't need to be checked synchronously 
at each request, and the cache can be checked either periodically or 
through external triggers.

So we end up with 3 main types of pipelines :
- non-caching,
- caching and synchronously validated,
- caching and asynchronously validated.

Thoughts ?

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message