Re: digest only peering?

On Wed, 25 Nov 1998, Alex Rousskov wrote:

> On Wed, 25 Nov 1998, Bruce Campbell wrote:
>
> > That still leaves a window of up to an hour between when we discard an
> > object/generate cache-digest without said object, and a when peer
> > retrieves the latest cache-digest without the object in it,
>
> (a) The window between digest rebuilt and other caches asking for a new
> digest should be small in most cases (several minutes, not an hour)

worst case is peer retrieves digest, we rebuild digest immediately after
(repeat ad nauseum) ... so the peer is eternally nearly one hour out of
sync with our cache-digest.

> (b) New digest in most cases is more than 90% the same as the old one so the
> rebuild itself will not cause a lot of false hits.

In a large cache it shouldn't.

> > possibly
> > longer if the peer is disconnected, during which time the peer's client
> > will get our 'Bugger off, not letting you have this object'.

(should rephrase that - if the peer 'misses' fetching a cache-digest due
 to the link between us and the peer being disconnected, then tries to
 fetch something based on data contained in an old cache-digest when
 connectivity returns.. etc)

> If a peer is disconnected, Squid will detect that and will not use the digest
> from that peer until the peer is back. Meantime, Squid will try to re-fresh
> the peer digest and is likely to fail (since the peer is disconnected) and
> disable the digest.

Ah, that bit of squid's behaviour I wasn't aware of. Will the peer also
disable using cache-digests until it has the latest and greatest copy
after it detects disconnection/reconnection of a (cache-digest) peer?

> > Skimming store_digest.c, around line 190 says "this object won't be added
> > to the digest as we're going to toss it out before the next rebuild", so
> > that seems to cover most cases, although I'd be inclined to trust in the
> > Note there and increase that amount of time, ie:
>
> You sure can do that. Just note that it will cause more false hits (handled
> correctly or not).

Huh? Wouldn't it cause less false hits as its reducing the number of
probable objects which may be false hits due to us tossing them out during
the lifetime of the next cache-digest (which the peer may not get in time)
?

(I'm referring to increasing the amount of time between now and when it is
 considered 'safe' to digestify an object based on their impending
 expiration time, ie, don't include the object if its going to expire in
 the next 3 hours instead of the (previous setting) next 1 hour)

> Also, you probably do not have to patch Squid to achieve
> similar effect. Try using the default "." refresh pattern for that (not
> exactly the same, but probably close). Refresh statistics in cache manager
> will show you how many objects (%) you have digested.

Oh no, I'm not mucking with refresh patterns. Bad things happen in our
peering arangements if I muck with refresh patterns; Everyone is using
the same black chicken. ;)

--==--
Bruce.

Sysadmin, TheHub.
Received on Wed Nov 25 1998 - 16:09:58 MST