[squid-users] caching store increase then decrease during caching windows updates and all request are TCP_MISS ??!!!

[Amos Jeffries]

On 13/09/2016 8:26 a.m., --Ahmad-- wrote:
> amos thank you so much for reply 
> 
> 
> how can i correct the patterns below ?
> 

Remove the ([^.]+.)? and ([^.]+.|) parts.

Replace the . where you want to match a '.' with \.


> 
> im not sure if the other patterns are doing the game 
> 
> but so far i don’t have disk increasing at all
> 
> only  the disk start increase when only i add :
>>> refresh_pattern ([^.]+.)?(download|(windows)?update).(microsoft.)?com/.*.(cab|exe|msi|msp|psf) 4320 100% 43200 reload-into-ims
>>> refresh_pattern ([^.]+.|)(download|adcdownload).(apple.|)com/.*.(pkg|dmg) 4320 100% 43200 reload-into-ins
> 
> but  i still don’t have HITs 
> 

You have many CLIENT_REFRESH/20x. Which means cached content was found,
but the client required it to be refreshed. When revalidated the server
returned an entire new object.

With the above refresh_rattern, the client may have required the cached
data to be reloaded (Cache-Control:max-age=0) and the reload-into-ims
converted it to a CLIENT_REFRESH from a MISS.


> im not sure where should i tune ?

There is not much you can do when the server returns whole objects in
response to revalidation requests.

The client is requiring that only the latest copy be used, and the
server is insisting that the object has changed.

Since this is an OS update process it is exremely unsafe to make
assumptions yourself about anything being differently cacheable than
what the server is insisting. It is entirely possible that each response
is encrypted and hashed independently - so actually is different.


> 
> i also added stip query terms to off
> 
> 
> not sure  what should i do next ……. all i need is windows updates go ok , I’m not interested with other caching 
> 

With query-terms in the access.log you can better see what requests
should be MISS and which ones have a chance of being HITs (or near-HITs).

Once you can tell which requests actually should be HIT-able you can
then look at the messages going through (in cache.log with debug_options
11,2) for those requests to see what else might be done.

Amos