On 10/13/2016 12:46 PM, Yuri Voinov wrote: > > > 14.10.2016 0:28, Alex Rousskov пишет: >> On 10/13/2016 11:52 AM, Yuri Voinov wrote: >>> When we seen ??????/304 with only headers - most probably content behind >>> proxy already and this is CLIENT_IMS_HIT observed. >> A 304 code sent by Squid to the client means "Squid told the client that >> the client has a fresh copy (or equivalent)". It does not tell us how >> Squid came up with that answer, or what Squid has in its cache: We do >> not know whether Squid had the corresponding entry cached when the >> client request came. If Squid had that entry cached, then Squid may or >> may not have tried to validate it. If Squid tried to validate, then >> Squid may or may not have gotten an entry from the origin server. >> Finally, we do not know whether Squid kept, replaced, or deleted the >> cache entry as the result of that validation attempt. > >> For an extreme example, consider Squid without a cache. Such a >> configuration will still have lots of /304 entries in access.log! > >> A single access.log line (and often even a single Squid result code on >> that line!) is telling us what happened when Squid talked to the client >> _and_ what happened when Squid talked to the server (if it did talk to >> the server). One cannot gain that vital information from a single HTTP >> status code alone. > > >> Many folks disagree regarding the best way to structure Squid result >> codes. Many also disagree regarding the best definition for "cache hit". >> All the different approaches make it very difficult to discuss these >> matters and maintain related code. A /304 field alone means the client >> got an HTTP 304 response. Whether you call that a "hit" from Squid point >> of view depends on your definition of "hit" _and_ (depending on that >> definition) on other factors that /304 does not reveal. For example: > >> * if your definition of a "hit" is "Squid did not talk to the origin >> server or peer", then /304 alone does not necessarily mean a hit. > But most probably, right? The probability is determined by the environment. I have already given you a simple example where _all_ /304s mean that Squid talked to the origin server. In that environment, the probability is 0. There are lots of environments. I do not know what is "most probable" in yours. >> * if your definition of a "hit" is "Squid did not receive a large >> response from the origin server or peer", then /304 alone does not >> necessarily mean a hit. > But still most probably, yes? Same answer. I have seen environments where this probability will be close to zero for this definition of a "hit". > Alone - agreed, Alex. But we've can see all transaction, right? Sure, but your original question was about /304 alone and you have resisted Amos' attempts to get more transaction information (AFAICT). > So, if we've already done request to the same URL in the past, got > TCP_MISS, then get again, _and_ has saved copy in cache, _and_ we're got > 304 - this is hit. For shared cache itself. Depends on your definition of a hit. And even if Squid cached Xv2 during the previous transaction, does not mean Squid did not revalidate Xv2 during the last transaction, did not receive Xv3 from a peer, and the client does not already have and is revalidating Xv4. Yes, there are certainly lots of cases where what you think is happening is actually happening, but there are other cases as well. > But: If something behaves like a hit, it looks like a hit and quacks > like a hit - it hit. :) Unfortunately, there are too many definitions of a "hit". Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
