On 16/07/2013 8:10 a.m., jc.yin wrote:
Haha I'm doing this for a client but having had to research all about Squid
the past week, I'm thinking of setting up my own as well :p
I think tomorrow I'll just set up a local Squid server to test out the
results. In the mean time I'll upload the squid.config file like Amos
suggested as soon as possible so you guys can take a look and see if any of
the settings I've tinkered with is causing Squid to not write/read from disk
cache.
Hi jc.yin,
To answer the questions you have had in the last few posts here is a
brief summary overview of how the caching works ...
Basically teh behavoiour you were seeing is that as others have said
there are *two* caches in play. Your Squid one and the browser cache.
Both are following the same rules for lifetime of objects and when they
need to be re-fetched. What that means is that everything *is* being
cached by Squid, however so is the browser. When the browser reaches the
point where it needs to re-fetch an object Squid has also just reached
the point of it being "stale" there as well and needs to REFRESH the object.
* This is one of the major problems when testing a Squid by yourself.
As the only user the two caches are kept almost exactly in-sync with
each other and Squid shows an extremely low HIT-rate purely as a
side-effect of being in-sync. Using F5/reload/force-refresh in the
browser does not help as reload forces a REFRESH in both caches and they
stay in-sync.
The only real way to avoid this problem is to remove the browser
cache (set it to 0 size, erase it between each fetch, use multiple
browsers, etc) or use a tool such as wget, curl or squidclient which
does not have a browser cache confusing things. The test with google
images pages is interesting but you do need to have small enough browser
cache that the whole page
The Squid memory cache in recent releases has been expanded to hold a
lot of objects in the fast-access memory cache. Do not worry yourself
about whether it is a TCP_HIT or a TCP_MEM_HIT at this stage - Squid
will use the fastest one available. The key thing is that it is a HIT.
Also a REFRESH means Squid had the object cached but needed to re-check
it for some reason, these are almost as good as a HIT for speed and the
metrics show them as near-HIT / near-MISS depending on whether the
refresh turnd out to be closer to HIT or MISS in terms of bandwidth
performance. In a great deal of cases Squid is allowed by HTTP/1.1 to
cache objects for bandwidth saving but required to refresh and check
that they are accurate before each use - saves a lot on bandwidth and
provides better UX in most cases.
In short, the result you seems to be reporting two mails ago looks like
your Squid is working well now. Mostly HIT or REFRESH and not much MISS.
Amos
