Re: upcoming changes to TTLs.

>
> > For the next 1.1 beta version I have changed the way Squid handles
> > object lifetimes. Instead of calculating a TTL when the object
> > enters the cache, it now checks for "freshness" or "staleness"
> > when the request is made.
>
> I think it is a great idea!

>
> > If the object age is less than 'min', it is fresh.
> > If the object expiry time has been reached, it is stale.
> > If the object age is more than 'max', it is stale.
>
> To ensure that all object is updated, min can be set
> to pretty low, or even 0. So, every object requested
> will be followed by a IMS request to the source.
>
> If the object is not updated, than the cached object
> will be returned to the user.
>
> There will be a performance reduction due to the
> latency time on the IMS check with the source.
> But it ensure that there will not be a stale object.

>
> I would prefer that all GET request to the source
> should be a GET IMS request unless there isn't previously
> cached object. I am not sure if that is the current
> behaviour of Squid.

 As all of us have realized from traditional computer architecture already,
 the tradeoff between staleness & additional overheads
 (user latency, bandwidth consumption, performance degradation, etc...)
 will play an important role on our travel -'The way to the Optimal Web Caching'
 
 Now Squid seems to be taking an important step towards our goal.
 Using simple ttl_pattern and limited support for handling IMS-requests
 were somewhat too short to test & experiment various cache policies.

 Perhaps this change will give cache administrators power/responsiveness
 more and more, for example, controlling minimum TTL values for every(?, I
 believe so.) objects. If clients themselves could control the staleness of
 objects they requested, it couldn't be better, though impossible right now.
 
 Hmm....What's next?
 Prefetching? replication?
 How much hit ratio we can get by mixing all of these mechanism?
 How much cost should we pay for it?
 Too many problems which should be solved......isn't it? :)

>
> *8)
> Ong Beng Hui
> ongbh@singnet.com.sg
> ...yet another day in an ISP business
> ...and they lived happily ever after
>
>

Best Regards, Hyunchul Kim

 - hckim@cosmos.kaist.ac.kr
Received on Mon Oct 28 1996 - 04:37:13 MST