cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] sharing latest research production (long!)
Date Thu, 15 Feb 2001 23:08:31 GMT
Paul Lamb wrote:
> 
> I've read you RT twice now and with your comments to Robin it does make
> sense. It brought back a real deja vu from over a decade ago when I sat
> through an entire day on the design and implementation of the scheduler,
> paging, MMU and TLD of the RS/6000 right after it first came out. Very
> similar thought processes.

I thank you for this. It's a very good compliment.
 
> My first thought on the formulas is what about when the first retrieval
> is hugely expensive, but after that it's not at all. I'm not sure where
> you'd put information like ignore the first x number of accesses.

Oh, no, nothing hugely expensive, the only thing that happens is that
the frequency of caching will depend on the efficiency, thus, the more
efficient, the least number of hits to reach nearly optimal caching
performance, the least efficient, the more hits, but since efficiency
was slow anyway, the net result is that no huge expense is taken.

Anyway, I plan to write a small "visual fake cache" to show you how the
cache works, something like a JMeter that estimates efficiency and
visualizes cache entries and level of efficiencies and you can modify
parameters at real time to show how it adapts.

I know, it's a toy, but it could give interesting views into the best
way to visualize efficiency information.
 
> >From a real-world, non theoretical, perspective the one that worries me
> is:
> >       +----------------------------------------------------------+
> >       | 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);                       |
> >       +----------------------------------------------------------+
> >
> 
> Here's the problem I see. I create a hash function that works great, the
> code goes into production for a year and then some really important
> person decides that there needs to be a change. The changes are
> relatively easily made to the producer but nobody thinks to update the
> hashing function. Now I've introduced the possibility that the wrong
> data will be pulled from the cache and delivered to someone. I'd really
> hate to try and track down a bug like this.
> 
> Secondly, hash functions themselves. For the programmer that's never
> done one before they can seem rather foreign; I'd wager that most have
> never even seen one, and very few have had to code one. And from
> experience it can require lots of testing to make sure it's 100%
> correct.
> 
> Am I missing something here? Is this a lot easier than I think?

No, you are totally right, from this perspective, it's a real pain in
the ass.

But luckily, Ricardo and I thought about a solution for this problem
(yes, I explained part of this RT to Ricardo weeks ago): re-inversion of
control.

Look at these interface:

 public interface Cacheable {
   public void fillPolicy(CachePolicy policy);
 }

 public interface CachePolicy {
    public void addDependency(String variableName, Object
variableValue);
    public void setTimeToLive(long seconds);
 }

The only thing you have to provide is the dependencies you have
(filename, cookie parameter value, time of the day, system load, etc)
and, if you have it, your time2live.

The cache will then generate the key for you based on all the
information you provided.

Isn't is smart? :) 

[while the previous RT is all mine, these advanced interface concepts
were developped by Ricardo and I who deserves full credit for bringing
new ideas into the old picture]

Please, find attached the document that Ricardo wrote to me that
describes parts of the cache discussion we had before he left Italy to
go back to Colombia. It contains some part that are obsoleted by my new
efficiency algorithm, but the overall concepts still hold and are more
implementation oriented than accademic so some of you might find them
more interesting.

Ricardo, do you copy?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
Mime
View raw message