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
operation.
> 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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
