cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Adaptive Caching [was Re: initial checkin of the Scheme code]
Date Sun, 16 Dec 2001 04:35:06 GMT
Answer inline:

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Sunday, December 16, 2001 1:15 AM
> 
> Paulo Gaspar wrote:
> 
> ...
>
> > Otherwise the cache can end up
> > "thinking" that a given document was very expensive just because it
> > happened to be requested when the system was going trough a load
> > peak, and it might take the place of a much more "expensive"
> > document which was always requested when the system was under lower
> > loads. If theses documents have long "cache lives" a lot of capacity
> > can be lost for long periods of time due to such accidents.
> 
> True, but the user doesn't give a damn about "what" influenced the
> slowness of the document, neither does the cache: it's the actual result
> which is sampled, so maybe the document could take 10ms to generate
> without load (and the cache might take 12ms) but under load it takes
> 25ms and the cache 23ms.
> 
> ...

All you say is true. The problem is with what I wrote - I did not get 
my message trough.

What I mean is that the cache could accumulate quite some wrong cost 
measurements for long periods of time if they would happen with 
resources having a long "cache life".

Lets say you have resources A and B and that, under low load, A takes 
100 ms to build and B takes 15 seconds. Lets also say that both have a
cache life of 24 hours.

If when A is first requested the system is under heavy load it night 
end up taking 30" to get (sh*t like this happens with database
resources). Half an hour later B is requested for the first time and 
the system is already under low load, so it takes those usual 15".

For the next (almost) 24 hours, the cache will think that A is more
expensive than B.

What I say is that this kind of error can happen a lot. That will 
have a different cost depending on the characteristics of the system
(e.g.: longer cache lives => higher cost).

  
> > However, as you also mention, there is the cost of sampling. If you
> > have a processing time expensive document "A" with a maximum cache
> > lifetime of 24 hours that is usually requested 100 times a day...
> > and then you sample how much time it takes to get it 100 times a
> > day, the accuracy gets better but the cost of the sampling is as
> > big as the cost of not caching at all.
> 
> Yes, but the frequency of sampling a resource is inversively
> proportional to the difference between the costs of the two choices.
>
> ...

Again, all you say is true. The problem is with what I wrote - I did 
not get my message trough. Really, what I wrote is open to different
interpretations.

I was talking about how silly is the silly possibility of having more
sample data just by not using stuff that is already cached.

In this silly scenario, the system would try to get more data about how
expensive a resource with long "cache life" is to get by, at "some" 
requests "along the day" getting the resource again from its origin and 
ignoring its cached version.

 
> > But usually you have families of documents that take a similar time
> > to process, like:
> >  - Articles with 4000 words or less without pictures stored in XML
> >    files;
> >  - Product records from a product catalog stored in a database;
> >  - Invoices with less than 10 items from a database.
> > 
> > If your time measurements are made per family, you will usually
> > end up with a much wider set of sample data and hence much more
> > representative results. 
> 
> how do you envision the cache estimating what a 'family of resources'
> is?

You have to tell it, as follows later in the text.


> > The system use will generate the repeated
> > samples and their distribution along the time (and along load peaks
> > and low load periods) will tend to be much more representative than
> > any other mechanism we could come up with.
> > 
> > Besides, your sampling data aggregated per family will take less
> > storage space, hence leaving more room for caching.
> > =:o)
> 
> good point.
 
It is the same you (better) described before in your reply with:

  True, but the user doesn't give a damn about "what" influenced the
  slowness of the document, neither does the cache: it's the actual result
  which is sampled, so maybe the document could take 10ms to generate
  without load (and the cache might take 12ms) but under load it takes
  25ms and the cache 23ms.

  This shows that the cost function is not CPU time or 'single document
  processing time', but it's a more global 'production time for that
  resource at this very time' and *MUST* include everything even your load
  peaks.


> > Now, you only mention one key generation method in your document:
> > 
> > >      | Result #2:                                               |
> > >      |                                                          |
> > >      | Each cacheable producer must generate the unique key of  |
> > >      | the resource given all the enviornment information at    |
> > >      | request time                                             |
> > >      |                                                          |
> > >      |   long generateKey(Enviornment e);                       |
> > 
> > Is this key per instance (the caching key) or per family/type of
> > resource?
> 
> per resource.

Maybe we have a vocabulary problem here:
  I think I do not understand what a resource is in Cocoon.
=:o/

Lets take my previous example:
> >  - Invoices with less than 10 items from a database.

What is a resource? Is it "Invoice detail view" or is it the "detail 
view of invoice number 5678665"?


> > The conclusion from all I wrote above is that a resource producer
> > should probably produce two keys: the cache key and a "sampling
> > family" key that would be use to aggregate cost sampling data.
> > From your document it is not clear is it is this that you propose.
> 
> I can't think of a way to come up with 'resource families', but I'm open
> to suggestions.

Not sure, first I need to understand what "resource" really means!
=:o)


> > I would also prefer string keys since I do not see a meaningful
> > performance gain on using longs and I see much easier use with
> > strings, but this is just my opinion.
> 
> Well, I do: new String() is the single most espensive operation in the
> java.lang package. 
> 
> The java golden rule for performance is: don't you strings if you can
> avoid it.

OTOH, if each request takes 10000 (ten thousand) times the time of 
creating a String and if creating the string really makes things much 
easier...


Have fun,
Paulo Gaspar

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


Mime
View raw message