-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Look at this: http://i.imgur.com/gbkU20r.png Pay your attention to reply times. With hit ratio not above 30% will also occurs unacceptable delays on clients. So, I see no reasons to have cache with low hit ratio in any case. IMHO need to tune cache more accurate to achieve maximum possible hit ratio. 02.09.15 16:23, Eliezer Croitoru пишет: > On 02/09/2015 13:00, Yuri Voinov wrote: >> >> I'm getting a very high hit ratio in my cache.And I do not intend to >> lower its with myself. Enough and that on the opposite side of the >> thousands of webmasters counteract caching their content on its own >> grounds. Beginning from YouTube. > > Well, Most sane server side caches do allow and work with a 304 validation and in many cases it's good. > Notice that I have not seen an access.log analyzer that counts re-validation successfully until now. > I do not know what the situation of your bandwidth usage or needs but there is a term which called "over caching" and it depends on the environment. > If you see that the cache is working for you with higher numbers then 30% consider that your cache maybe is caching more then the standard cache. > I am pretty sure that a domain analysis can find the more accurate refresh_patterns that can leave you with high cache hit ratio and still make the cache less vulnerable to config mistakes. > > Maybe clients didn't complained until now but it doesn't states that they do not have any issues. It's just that they didn't got to you yet. > If you are using 3.4.X and up you are in a better place then in 3.2.X and older version so squid should be safe enough for a very ambitious config file. > > All The Bests, > Eliezer > > * Thanks for sharing the refresh_patterns discussion with others > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV5upFAAoJENNXIZxhPexGrVwH/iFVvW7/USt4//dGaqtcRBvA dXl893Fh6KAVjfiHSf9LKN+UArdkf2cAgoAiRVkqZWaq9BEyytfAdFUxEpxkUWfQ +d1B68UiPr3SABI2jqyice5763L4E+59ltPtOaId+D+e6QvWlPuhOY4YS+CYMolq YBPO3ofvvJNIrM0mOx09ewcYjdJnPyjeTEVe3DVDfrouqbd3qgGR6JeVyexUh8q1 wgWpFXW1X0nm2Pc28sHVdNjRVfpsh+VW95MSmUqqzap+ouG8Y78CJqWamw9QBav2 d64NjyyQ9aICLzpw6k8Lt4exQoozfN/DAI9uJOUi4HzZdn/48oSc6UNwIgQVVt4= =NPuB -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users