Re: [squid-users] RE: Squid Cache NEVER HIT's Only get TCP_MISS/200 and TCP_MISS/304

On 7/03/2014 11:53 p.m., Robin Gwynne wrote:
> My copy and paste was not correct in the original post. I have corrected my conf file below.
>
> Robin
>
> -----Original Message-----
> From: Robin Gwynne [mailto:Robin.Gwynne_at_wrbm.com]
> Sent: 07 March 2014 10:46
> To: squid-users_at_squid-cache.org
> Subject: [squid-users] Squid Cache NEVER HIT's Only get TCP_MISS/200 and TCP_MISS/304
>
>
> I am struggling with my Squid Reverse proxy cache. I have been all round the forums with no success in getting my Squid Proxy Cache to actually do any caching. I am running Squid 3.1 on Debian 6
>
> Can anyone suggest what might be wrong with my Squid.conf file? I have verified that the correct permissions exist on the cache folder, cache folders are initialized, no errors are returned from running "squid3 -k parse"
>
> Regards,
>
> Robin
>
> --------------Squid.conf----------------------
> http_port 80 accel ignore-cc defaultsite=richmedia.mydomain.com
> cache_mem 500 MB
> maximum_object_size_in_memory 50000 KB
> cache_dir ufs /var/spool/squid3 10000 32 512 max-size=10485760
> minimum_object_size 2 KB maximum_object_size 5000 MB

So you to get thsis straight:
 up to 50MB objects are allowed to cache in memory
 up to 10MB are allowed to cache on disk
 nothing smaller than 2KB is allowed to be cached

> refresh_pattern -i \.(gif|png|jpg|jpeg|ico|bmp|xml)$ 260000 90% 260009
> refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv|mpg|wma|ogg|wmv|asx|asf)$ 260000 90% 260009
> refresh_pattern . 260000 90% 260009
> acl xdomain urlpath_regex ^/crossdomain.xml
> cache_peer 94.125.16.13 parent 80 0 no-query no-digest originserver name=server1
> cache_peer_access server1 deny xdomain
> cache_peer 162.13.17.12 parent 8080 0 no-query no-digest originserver name=server2
> cache_peer_access server2 allow xdomain
> cache_peer_access server2 deny all
> cache allow all
> http_access allow all

Security note:

  The way you have designed the http_access and cache_peer_access rules
means that almost all attack traffic delivered to your Squid will be
relayed through the server1.

One of the benefits of having a reverse-proxy is to protect the backend
servers against those types of request. I highly recommend adding a
dstdomain ACL defining what domain(s) you host and using that for
http_access allow instead of acccepting everything.

> ------------------Access.log output----------------------
> 1394187754.972 108 195.157.14.29 TCP_MISS/200 118376 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187754.992 30 62.232.36.16 TCP_MISS/200 1004 GET http://richmedia.mydomain.com/favicon.ico - FIRST_UP_PARENT/server1 image/x-icon
> 1394187755.163 94 62.232.36.16 TCP_MISS/200 68954 GET http://richmedia.mydomain.com/media/webinar/supplier/I-Holland-2013Webinar/slides/Slide00029.swf - FIRST_UP_PARENT/server1 application/x-shockwave-flash
> 1394187765.378 9794 195.157.14.29 TCP_MISS/200 1696587 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187768.885 136 195.157.14.29 TCP_MISS/200 169077 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187782.779 38 62.232.3.16 TCP_MISS/200 1611 GET http://richmedia.mydomain.com/media/webinar/supplier/I-Holland-2013Webinar/slides/Slide624911.htm - FIRST_UP_PARENT/server1 text/html
> 1394187783.461 35 79.171.8.14 TCP_MISS/200 8811 GET http://richmedia.mydomain.com/media/webinar/supplier/Kampffmeyer-14Nov13/index.htm - FIRST_UP_PARENT/server1 text/html
> 1394187788.851 19370 195.157.14.29 TCP_MISS/200 3110156 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187792.101 66784 195.157.14.29 TCP_MISS/206 3961057 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187793.415 100 195.157.14.29 TCP_MISS/200 154126 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187807.537 13461 195.157.14.29 TCP_MISS/200 2109420 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187819.670 3 95.131.10.18 TCP_MISS/200 607 GET http://richmedia.mydomain.com/crossdomain.xml - FIRST_UP_PARENT/server2 application/xml
> 1394187838.664 144 195.157.14.29 TCP_MISS/200 115568 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
> 1394187855.303 35596 95.131.10.18 TCP_MISS/200 75550871 GET http://richmedia.mydomain.com/content/download/424921/8844388/file/Apprenticeships.mp4 - FIRST_UP_PARENT/server1 video/mp4
> 1394187867.488 28168 195.157.14.29 TCP_MISS/200 3961100 GET http://richmedia.mydomain.com/content/download/383683/8226052/file/Tim%20Storer.mp3 - FIRST_UP_PARENT/server1 audio/mpeg
>

The response object sizes are constantly changing!!

That means any one of a few things (in order of suspected likelihood):

* the requests are Range requests
 - which your Squid is not able to cache.
 - check for Range headers from the cleients then look into
range_offset_limit, quick_abort_min/max etc.
  ==> your log has one entry "TCP_MISS/206" which is a response to a
Range request.

* the objects being fetched might actually be different objects
 - so they actually *are* always MISS on the previously cached object.
 - sometimes this is caused by UA encoding. Check for Accept-Encoding
header differences and see if dropping that header on traffic to the
peer helps improve the HIT rate.

* the clients might be abandoning the connections before response completes
 - the quick_abort_* settings can help here. But YMMV with large objects.

Amos
Received on Sat Mar 08 2014 - 01:44:27 MST