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@xxxxxxxx] > Sent: 07 March 2014 10:46 > To: squid-users@xxxxxxxxxxxxxxx > Subject: 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
