Re: Cache digests of partly-fetched objects?

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Fri, 6 Nov 1998 10:45:48 -0700 (MST)

On Fri, 6 Nov 1998, John Sloan wrote:

> I'm sorry, I don't understand. I'm running squid-2.0.PATCH2 which does
> have a refreshWhen function in refresh.c.

Then you need to upgrade to the most recent 2.1.PRE version or wait till 2.1
will be RELeased. refreshWhen() is out-of-sync with the rest of the refresh
code. It was eliminated in recent PRE versions. It is possible to run the old
code and get decent results, but it is much harder to understand what is
going on when results are not satisfactory.
 
> I have no idea what I'm looking for. You will need to be more specific.

Same thing. The detailed stats under "Refresh Algorithm Statistics" were
significantly enhanced in recent PRE versions of Squid 2.1. What you are
looking now with 2.0 version is probably not very useful for our purposes.
  
> > - select a few false hits of your choice and verify _why_
> > they were false. You can check the headers of the replies
> > for X-Cache-Lookup and X-Cache entries.
>
> Presumably only if I log the headers.

No. Standard logs will tell you when a cache served a false hit to a peer.
Then you can play with that object using ./client program to get the headers
and reconstruct what happened. You do have to analyze very fresh log entries,
but you do not have to log the headers.
 
> How does this help me find out why I got a cache_digest_hit for an
> uncacheable object? [One which was too big]

There are two possibilities.
        - there was a collision in the digest; i.e. the object in question
          was _not_ digested, but appeared to be in the digest because of the
          collision with other entries.
        - the object was digested by mistake.

If you know the headers, you can see if Squid had enough information not to
digest an object (e.g. content length was known a priory or no-cache pragma
was specified, etc.)
 
> I'm now thoroughly confused. Please bear in mind that I'm not intimately
> familiar with the code and how it works.

Right. That is why the best strategy is to reconstruct what happened and
proceed from there...

Alex.
Received on Fri Nov 06 1998 - 10:43:57 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:58 MST