On 19/08/11 02:40, Kaiwang Chen wrote:
2011/8/18 Amos Jeffries<squid3@xxxxxxxxxxxxx>:
On 18/08/11 22:53, Kaiwang Chen wrote:
2011/8/18 Amos Jeffries<squid3@xxxxxxxxxxxxx>:
On 18/08/11 19:40, Drunkard Zhang wrote:
2011/8/18 Chen Bangzhong:
<snip>
I don't know why there are so many disk writes and there are so many
objects on disk.
All traffic goes through either RAM cache or if its bigger than
maximum_object_size_in_memory will go through disks.
From that info report ~60% of your traffic bytes are MISS responses. A
large
portion of that MISS traffic is likely not storable, so will be written
to
cache then discarded immediately. Squid is overall mostly-write with its
disk behaviour.
Will a "cache deny" matching those non-storable objects suppress
storing them to disk?
And HTTP header 'Cache-Control: no-store' ?
"no-store" header and "cache deny" directive have the same effect on your
Squid. Both erase existing stored objects and erase the newely received one
_after_ it is finished transfer.
The difference is that the header applies everywhere receiving the object.
The cache access control is limited to that one Squid instance testing it.
Great. What about "Cache-Control: max-age=0" and "Cache-Control:
no-cache" responses? Does squid store them,
max-age=0, that means discard immediately. Same as no-store to Squid.
no-cache on responses is borderline. I can't seem to find anything
relevant to no-cache kicking off a refresh. The HTTP/1.1 support results
show it acting like no-store when last tested. So probably not usable yet.
Luckily there is an overlap with the must-revalidate response directive.
You can send that on the reply instead.
> hoping it is cheaper to
> make a validatation than to fetch a whole fresh object? Which souce
> code files describe the logic to deal with such cases?
>
If the object has not actually changed, the server sends 304 instead of
a new object, and there is an ETag to identify that object both machines
are talking about is identical. Then yes, revalidation is much smaller.
Squid does not (yet) send If-None-Match on revalidations (accepts and
relay it but does not create it), so there are a number of possible
cases where revalidation fails to be smaller.
src/client_side_reply.cc cacheHit() handles the reply when an object is
found in storage (to determin if its usable, obsolete, or simply old).
That makes use of various other process*() code and src/refresh.cc does
the revalidation calculations.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
