Re: [squid-users] squid performance tunning

On 19/08/11 02:40, Kaiwang Chen wrote:
> 2011/8/18 Amos Jeffries<squid3_at_treenet.co.nz>:
>> On 18/08/11 22:53, Kaiwang Chen wrote:
>>>
>>> 2011/8/18 Amos Jeffries<squid3_at_treenet.co.nz>:
>>>>
>>>> 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