Re: hierarchy_stoplist & cache digests

On Thu, 13 May 1999, Henrik Nordstrom wrote:

> In my opinion _posetively_ includes that we can accept a IMS query on
> that object, which currently limits us to status 200 objects. So perhaps
> a simple flag is sufficient (lets call that flag "standard cachable
> object" for the rest of this discussion)

I agree. Ideally, one may want several flags: digestible, ICP-"hitable",
etc. However, having one flag seems to be sufficient for most purposes.

> This also reminds me of the old issue of refresh patterns, in-memory
> timestams and cache digest. In my opinion only one object timestamp
> needs to be kept in memory: when the object needs to be refreshed next.

Before rushing into deleting the other timestamps, I want to ask people
who actualy put the timestamps in -- what was the intention of having
other timestamps memory-resident? Is there something we are missing
here?

Thanks,

Alex.

> Summary:
> * Add one flag for telling if this is an normal cachable object which it
> is reasonable to report as hit to peers (both ICP and digest). provided
> that it also is fresh of course. The flag should be configurable with a
> ACL like check (preferably having access to object information like
> content-type and/or length besides the URL and other "standard"
> information).
> * Remove the current 3 object timestamps (Date, Last-Modified, Expires)
> and replace them with a single "Fresh Until" timestamp based on refresh
> patterns.
>
> Both these new values ("normal cachable" flag, and "fresh until"
> timestamp) is estimated values based on the settings when the object
> last was touched. Updated each time the object is hit to allow for more
> rapid propagation of configuration changes to the cache policy.
>
> Objects which are both fresh enough and classified as "normal cachable"
> gets digested, and is reported as ICP hits.
>
> This should provide a simple framework which saves memory (2 timestamps
> or 8 bytes less / object on most platforms), makes digesting a lighter
> task and allows for detailed control of what gets digested or reported
> as ICP hits.
>
> Drawbacks:
> * Not entirely obvious how to upgrade a existing cache without either
> doing from disk rebuild, or temporarily resetting "fresh until" to the
> default TTL as used when building digests.
> * Needs changes here and there in the code.
>
> On the positive side can be noted that the on disk store format is
> flexible enoght to easily allow the change while preserving old objects.
>
>
> Hmm.. thinking a bit further on what can be removed from memory: We do
> not really need the "last referenced" timestamp either. The LRU list is
> sufficient, and can be preserved by writing out the swap index based on
> the LRU list when ever we write a clean swap index.
>
> /Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT