Search squid archive

Re: caching store increase then decrease during caching windows updates and all request are TCP_MISS ??!!!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just as a side note to the server insisting on the full object:
Since we believe and estimate that SHA digests are considered collision safe on the 100+ MB files sizes for the next couple years it is safe to assume(from my point of view on things) that if the whole file was digested with a SHA1 and forward and the full object was found to match this same SHA1 (or other digest) it is safe to be cached.
However I must admit that if these is some communication channel over this url such as in the headers, it would be possible to assume that you cannot cache this content.
With all the above in mind I think that Caching Windows Updates in most cases might not be the right path.
Only if you can provide much  beefier compute and storage resources then the original source it would be smart to cache these.

When an admin will try to cache with a much slower and less performing system then the original one it would be pretty simple to estimate that it will "slow down" things for the clients in many cases.
The practical example I can give is using a 5400RPM spinning disk for a cache which utilizes more then 100 IOPs from disk.

I believe that this should only be used when there are cases which you took anything you can into consideration and consulted any engineer which you should.

All The Bests,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer@xxxxxxxxxxxx


-----Original Message-----
From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Amos Jeffries
Sent: Tuesday, September 13, 2016 6:05 AM
To: --Ahmad--
Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  caching store increase then decrease during caching windows updates and all request are TCP_MISS ??!!!

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

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux