cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: cache and performance
Date Wed, 05 Jul 2000 17:33:55 GMT
Ed Staub wrote:
> Stefano wrote:
> >> What are the caching strategy for the XML,XSLT,XSP,SQL parts in Cocoon1
> >>vs. Cocoon2?!
> >Exactly the same: we provide the caching architecture, you write your
> >caching strategy.
> It's often expensive to check whether a cached resource has changed.

Yes. But normally people get smart when they have to save time. (and
please their bosses)

> In particular, accessing a database to see if change has occurred 
> may be as expensive as retrieving the original data.

True. This is why I normally suggest to use inversion of control even in
such situations. For example, create a "flaggable" resource (file, LDAP,
internal) that the database can access when updated.

If your database is smart enough (or the logic that updates the database
is), you can "signal" the resource has changed so the cocoon logic just
have to check synchronously a local (or faster) resource.

Of course, there are cases where you can't do this, expecially in highly
relational data.... but this is why the strategy is left to you: we
can't possibly estimate your caching needs besides providing default
ones for simple resources like files and URIs.

> In many (perhaps most) uses of resource inclusion, it's ok to use slightly
> stale information in a production environment.
> It might be useful to provide resource-consuming documents with a uniform
> way of specifying just how "fresh" the consumed resource must be.  This
> would eliminate unnecessary checking and cache reloads.

you mean sort of "time-to-live"? well, yes, it reduces load but may
generate inconsistent resources when, for example, one included resource
timeout elapsed and the other one did not.

So you need a way to "synchronize" the timeouts based on which classes
of inclusions your resource happens to be... updating this graph of
inclusions might even be more expensive than the synchronous change
> In cases where the consumer of the resource is also a cached resource, the
> effect COULD be recursive; the consumer would potentially make more
> effective use of caching also.  In order for this to be effective, the
> processor of the consuming document would require a way to quickly traverse
> the set of consumed resources, without processing the entire document. There
> may be some significant design issues here.

Yes, there are, but we have postponed any design dicision about caching
later on because we want to implement something that works first (for
> For example, an XInclude element might include a new attribute:
>         <xinclude:include href="something.xml" cache-expire="P10M"/>
> to say that the cache for this inclusion need only be checked every ten
> minutes. (The "P10M" is in ISO 8601 syntax.)

I think might be worth adding, yes.
> If folks here in CocoonLand see any merit in this notion, I'll also drop a
> note on the W3C XInclude group.

I'd say go for it and tell us what you discovered.

But keep in mind W3C is normally not focused on server-side issues so
you might find lots of resistance in this path.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message