Re: Hot object cache

On Mon, 2002-10-21 at 09:35, Henrik Nordström wrote:
> On 21 Oct 2002, Robert Collins wrote:
>
> > Whilst this will reduce the memory races, it won't benefit the hot
> > object cache directly. The change I am proposing (IMO) gives the hot
> > object cache for free.
>
> The memory/object size races is sufficient to call for this I think. I
> don't see anything in your proposal that fixes this in a good manner.
>
> Corner example case:
>
> Server object is 1GB large, content-length unknown. When 20
> KB has been retreived we get another request for the same object.
>
> First client is a modem user downloading at about 5K /second. The second
> client is a DSL or other high speed client downloading at a significantly
> higher rate (also consider opposite situation)
>
> We do not want to cache objects larger than 20MB.
>
>
> How do we handle these two requests?

This one *seems* trivial. storeGetPublic should not find an object that
is not cachable. So the second client will get a new storeEntry.
 
> And I do not see at all how the single/multi client decision relates to
> ranges, neither either processing or merging..

It relates to merging.
If we have a set X that contains portions of object foo, in cache. Then
requests for object foo will use the same storeEntry.

Now, if we have a single client logic, then we cannot satisfy more than
one client from the cache, if data is missing. A multi client logic
allows us to do that.

> > Recording LRU data in each datastream fragment.
> Minor Note: hot object caches is where using other replacement policied
> than LRU is proven to be useful..

Yep. Note my first email on this implied the ability to use multiple
replacement policies, with LRU first of the rank due to it's triviality.
 
> > Let me put it this way: I need to alter the swapout code for fix ranges.
> > I have a couple of choices. Do you object to the one I suggested?
>
> Looks fine at a first glance, but I am a little unsure on the detail of
> having swapout as a store client..

Ok. I'll enlarge on this this afternoon. Basic detail is:
Remove all current storeSwapout API calls.
Create a new API call i.e.: StoreSwapper *createSwapper(StoreEntry &,
HttpReply &, request_t &).
This call will create an object that will:
Check the swapout policy and do nothing if the object is not to be disk
cached. (which includes having range data for now).
Otherwise:
Start reading the object at offset 0, and will sequentially read through
and swap out until the object is:
* Aborted (remove disk object (for now)).
* EOF is reached.

This gets rid of all the callHandlers + storeSwapFoo call pairs, it's
all done through the handlers.

Rob