cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Adaptive Caching [was Re: initial checkin of the Scheme code]
Date Wed, 19 Dec 2001 16:39:29 GMT
Paulo Gaspar wrote:

> > So, please, try to see the entire system and not the single page.
> Of course. I am NOT saying "we must have no errors", I am saying "maybe
> we could have less errors".

Absolutely, if you have ideas on how to do a better sampling than what I
explained, I'll be very happy to hear them.

> > A "resource", in this case, is every document fragment at all levels,
> > the output of each pipeline component.
> Yes, I understand that the Cache can work in terms of fragments at all
> levels and so.
> What I do not understand is: having an XML fragment produced by a given
> generator (that gets an invoice from the database and "translates" it
> into XML), do you _always_ track costs per each invoice instance comming
> from that generator (one entry with the average cost of generating XML
> for invoice #12456 and another one for invoice #12122) or could you keep
> ONE cost entry aggregating the cost of all invoices comming from that
> generator (only one entry with the average cost of generating XML for
> any invoice, #12456's cost added together with #12122's).

Sorry, I didn't understand what you were saying.

Please, allow me to restate: the 'cost' is only one: how much it takes
to process an entire request.

> If in the case above all the invoices "produced" are very similar, the
> cache could measure their cost together, using a single sampling key for
> all the invoices produced by the above generator (although each invoice
> would still have a different cache storage key, of course).

well, if you still need a differen cache storage key, why would you need
a different sampling key?

Keep in mind that when the cache content is invalid, the single fragment
must be regenerated and this can be used for sampling.

In real situations, I really don't see sampling as an expensive
> In such situations, if a Cocoon developer could _optionally_ supply a
> "cost family" key the cache could have much better cost data (more
> frequent measurements, since any invoice generated contributes to the
> same measurement pool) and this cost data would take less space (same
> cost data for all the invoice instances).

Yeah, could be a good way to reduce memory consumption for cache data
(which is admittedly, lots of data anyway)
> Maybe this is already what you have in mind, but we are having a
> communication problem around this one.

No, thanks for telling me.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message