Re: [squid-users] MISSes on cacheable object

On 21/04/2014 6:56 p.m., Timur Irmatov wrote:
> After adding debug_options ALL,2 I see following in cache.log (attached):
>
> 2014/04/21 11:46:03.940 kid1| http.cc(750) processReplyHeader: HTTP
> Server REPLY:
> ---------
> HTTP/1.1 200 OK
> Server: nginx
> Date: Mon, 21 Apr 2014 06:43:03 GMT
> Content-Type: application/octet-stream
> Last-Modified: Fri, 04 Apr 2014 14:34:09 GMT
> Accept-Ranges: bytes
> Content-Length: 6779936
> Connection: Keep-Alive
> Age: 180
>
> MZ<90>
> ----------
> 2014/04/21 11:46:03.940 kid1| ctx: exit level 0
> 2014/04/21 11:46:03.940 kid1| store.cc(1011) checkCachable:
> StoreEntry::checkCachable: NO: not cachable
>
> So Squid considers servers reply uncacheable. Why?
>

Something (unknown) has marked it to be discarded before it finished
arriving. There is no sign of the store lookup logics looking up an
existing entry either.
 And ALL,6 trace (very big) will probaly be needed for that one.

There are two other obvious things to check.

The first is that this request is arriving on the tproxy port and the
domain name appears to be using different IPs in geographic based
responses. Is the Squid box getting the same 217.69.139.110 destination
as the client was contacting?
 debug option 78,3

The second is the storeid helper. What is its output?
 debug option 84,9

Amos
Received on Mon Apr 21 2014 - 09:06:42 MDT