On 28/10/2013 1:29 p.m., Manuel wrote:
Hi Eliezer, thank you for your answer
The origin servers are the same in 2.6 and in 3.3 (in both cases Squid
connect to the same origin remote servers) and the squid.conf is exactly the
same except in the very first lines (since acl manager proto cache_object ,
etc. are obsolote).
2.6 is HTTP/1.0 with a little HTTP/1.1 functionality. Squid-3.3 is fully
HTTP/1.1.
As Eliezer already mentioned the caching behaviour in each protocol is
very different. Down to and including the fact that 3.3 caches far
*more* content than 2.6 will, which can reduce the HIT ratio due to not
having the storage space for the longer-term objects that were
previously giving good HIT rate.
The vast majority of the misses are TCP_MISS/200. I checked several times
the last 200 requests to the homepage of our site (the min/max age is 1
minute -but also tried with a few more minutes-) in the access.log file and
these were the results:
Squid 2.6:
1st check: 5 misses of 200 requests
2nd check: 0 misses of 200 requests
3rd check: 2 misses of 200 requests
Squid 3.3:
1st check: 59 misses of 200 requests
2nd check: 32 misses of 200 requests
3rd check: 108 misses of 200 requests
*Nothing was touched between each check, just a pause of a few seconds or
minutes.
What would the URL of that page be?
What does the tool at redbot.org say about its cacheability?
And what are the refresh_patterns in use?
How was the check made?
How big is your cache storage?
redbot.org is an invaluable tool for identifying what the HTTP behaviour
is expected to be for any given URL. It tests multiple different request
types HTTP/1.1 can contain.
The 3.3 versino of Squid with debug_options 11,2 configured will log to
cache.log a full set of the HTTP request and reply headers on each
in/outbound connection so you can see what exact case the proxy is
facing and determine what the expected behaviour should actually have been.
Note that the logged status is client-focused, the server status may be
very different. Although in the specific case of "TCP_MISS/200" the
cache storage is not supposed to have been involved so the client and
server replies should be near identical.
I was think that maybe I should --enable-http-violations in Squid3.3 to get
use of override-expire ignore-reload but I think that it is already enabled
by default since negative_ttl is working properly and requires
--enable-http-violations . Indeed I reduced some misses by using
negative_ttl on squid.conf because Squid3.3 was doing misses with 404
requests while Squid2.6 was doing hits without the need of setting that
directive.
Violations is on by default in the name of tolerance since there are so
many, many broken clients and servers out there.
If you can tune those 404 responses to contain Cache-Control allowing
storage it would be better. negative_ttl stores many errors and can
result in a self-induced DoS against its own clients.
It sounds like you are running the web server. If so you should look
into the cacheability of response objects then tune the web server
responses. There are many other caches around the world also storing
your content and to make the best benefit of them your site needs to
work without violations. As the Squid warnings say, using violations
places responsibility for brokenness on the admin using them - dont feel
obliged to tune your origin server output much for incompetence
elsewhere, Squid and other proxy software is already doing as much as
possible to compliance-correct the traffic.
Amos
