Re: Cache Digest just doesn't work?

On Wed, 7 Oct 1998, Teemu Peltonen wrote:

> I experimented with an empty proxy. The requested URL was not in cache, but
> it is on a very popular page, so I was sure it was on other caches of the
> cluster.

Note that being popular does not imply being cached or cached for
sufficiently long time. You have to send GET request with only-if-cached
Cache-Control directive or do something similar to be sure the page is cached
and digested.
 
> 1998/10/07 12:44:48| fwdStart: 'http://194.100.30.109/kuvat/ala2.gif'
> 1998/10/07 12:44:48| peerSelect: http://194.100.30.109/kuvat/ala2.gif
> 1998/10/07 12:44:48| peerSelectFoo: 'HEAD 194.100.30.109'
> 1998/10/07 12:44:48| peerSelectFoo: direct = DIRECT_MAYBE
> 1998/10/07 12:44:48| peerDigestLookup: peer themis.netti.fi
> 1998/10/07 12:44:48| peerDigestLookup: Usable!
> 1998/10/07 12:44:48| peerDigestLookup: OK to lookup peer themis.netti.fi
> 1998/10/07 12:44:48| cacheDigestHashKey: E8E18DE17147D3C66535B158427C4542 -(2129192)-> 28713 1293414 1051600 1873034
>
> So far so good, it was found on themis.

Nope. The object was looked up in the digest, but the digest returned MISS!
You would see
        neighborsDigestPeerLookup: peer themis.netti.fi says HIT
in case of a HIT.

> 1998/10/07 12:44:48| peerDigestLookup: peer mnemosyne.netti.fi
> 1998/10/07 12:44:48| peerDigestLookup: Usable!
> 1998/10/07 12:44:48| peerDigestLookup: OK to lookup peer mnemosyne.netti.fi
> 1998/10/07 12:44:48| cacheDigestHashKey: E8E18DE17147D3C66535B158427C4542 -(868896)-> 539617 257126 194840 646882
>
> So far so good, it was found also on mnemosyne.

Same thing, MISS in this digest as well.

> 1998/10/07 12:44:48| neighborsDigestSelect: choices: 2 (0)
>
> That makes two possibilities. I guess it's ok to have ichoice_count 0 here?

Yes, there were two _usable_ digests and none of them had RTT info from NetDB
module.

> 1998/10/07 12:44:48| peerNoteDigestLookup: peer <none>, lookup: LOOKUP_MISS
>
> What is this? There are only two peers defined, why this row appears? Is it
> standard or do I have a typo in my config file?

It appears because both usable digests returned MISS.

> 1998/10/07 12:44:48| peerSelectIcpPing: http://194.100.30.109/kuvat/ala2.gif
> 1998/10/07 12:44:48| peerSelectFoo: After peerSelectIcpPing.
>
> This is OK too, I guess..

These lines indicate that Squid is considering pinging peers with ICP.

> 1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
> 1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
> 1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
> 1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
>
> But then again, what is this?

Not sure, but this is normal. :)

> So my problem seems to be in the peer selection algorithm rather than in
> digests. Any ideas?

At this point, we still do not know if that page was supposed to be in those
two digests. You can try that only-if-cached trick above to see if the page
is cached on your peers _and_ when it expires. Pages that expire sooner than
digest rebuilt are not digested.

Sometimes I find the following technique useful: Request a "perfect" page
from your peer cache. Wait for next digest exchange (you can force it buy
restarting the local cache). Repeat the tests above.

N.B. The "perfect" page should be cachable and have a huge expiration time
(with max-age and Expires:). Again, verify that the page is cached with
only-if-cached trick.

Alex.
Received on Wed Oct 07 1998 - 10:11:25 MDT