[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


14.10.2016 1:28, Alex Rousskov пишет:
> 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).
Mea culpa. I thought it obvious that, once I show an entry from the log,
I have entire log and, of course, that this is only part of the
transaction, which sees the whole entire proxy.

However, this is nothing more than word games, Alex. The question is -
can we more or less significant differences from known what hit proxy
code level and / or transactions which, obviously, on the proxy level,
we can see in its entirety.
>
>
>
>> 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".
There is no many definitions of hit. We are talking about the caching
proxy, which is basically no different from all the other caches, and
subject to the same rules.

_If the first access does not find an object in the cache, it requests
from the network, saves in the cache, and re-treatment or gets a hit,
"the object is not changed." Dot. Further. If the time in the cache
object lifetime expires, or a lifetime on the server timed out - the
object is requested again and a miss is recorded._

The fact that we do not know that there is a client with the object? It
is not our business. It is the client's problem. If the client cache get
miss for an object that no longer exists or its lifetime has expired -
he asks his proxy. Proxy, in the future, or fixes hit or miss. Thus, if
the proxy responds to the client "has not changed", it means, in fact,
that the client has a copy of the object and a copy of the proxy object,
the proxy and responds to the client, performing REFRESH that the object
did not change. What is this, if not hit?

>
>
> Alex.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX/+QeAAoJENNXIZxhPexGXaUH/0b+UkESSCj/oFxSSOfyJyJJ
IcqBxSWh8A9H6AQKco2i8P7Gjlr7oAGZsbF3YS+Gzr3F0ixVIBHdTOW5aXrhjWzm
wyLeeZsmLh7vD4sSAA3IbO9xvvG01sIWnRekagdpE/Smg7tJNoGC84GInQKbEsCm
2wMrdhb7sxE56kc9OmpcYZ7RghwWr0rqSZZ0S62xW0jSkffbUBUTiyRPQox+uZ9a
YCwZ9Ant+6+yrNzoMA9Yn2ujRD7OvuIlsC/pNZ4GqyIU5NJ+wjvfdbt6rx5l/dcr
DICdfi/adNegw9vF9DG4lm9i2joGFo7+OPzKoQeyuO3f7bLSdyxGapxIVWjTNr8=
=jHaY
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161014/b519ae93/attachment.key>