<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
It seems I found the root of problem.<br>
<br>
When cached object refreshed and goes via HTTP, it gives
TCP_REFRESH_UNMODIFIED in access.log, which is correct.<br>
When the _same_ _cached_ _object_ refreshes and goes via HTTPS, it
gives TCP_MISS/304 in access.log, and this is wrong.<br>
<br>
It seems like bug.<br>
<br>
14.10.2016 3:44, Yuri Voinov пишет:<br>
<span style="white-space: pre;">><br>
><br>
><br>
> 14.10.2016 2:48, Alex Rousskov пишет:<br>
> > On 10/13/2016 01:44 PM, Yuri Voinov wrote:<br>
><br>
> >> However, this is nothing more than word games, Alex.<br>
><br>
> > ... unless the definition of a hit affects your billing
or your<br>
> > interpretation of Squid documentation or the developer
interpretation of<br>
> > the code. Definitions matter! You yourself have seen
their importance<br>
> > when you showed your excellent byte hit ratio results
but folks were<br>
> > looking at the ordinary document hit ratio numbers
instead.<br>
> Sure. But difference with TCP_HIT itself and byte hit is
obvious.<br>
><br>
><br>
><br>
> >> The question is -<br>
> >> can we more or less significant differences from
known what hit proxy<br>
> >> code level and / or transactions which, obviously,
on the proxy level,<br>
> >> we can see in its entirety.<br>
><br>
> > Sorry, I do not understand the question.<br>
> I want to say that on the proxy level, seeing the transaction
as a<br>
> whole, we are able to differentiate hit or his likeness from
all other<br>
> transactions. We see the whole session in its entirety. We
see repeated<br>
> queries of the same client to the same resource. Accordingly,
we can<br>
> quite clearly be judged by the behavior of the header from
the client or<br>
> server that is happening. Correctly?<br>
><br>
> Specifically, in this particular case. Proxy IMS settings is
enabled:<br>
><br>
> refresh_all_ims on<br>
> reload_into_ims on<br>
><br>
> On web-page level we have: periodically reload/refresh
directive, which<br>
> is forces to check (after initially store in shared cache)
freshness of<br>
> content.<br>
><br>
> In this situation (and I've checked this web-page elements
stored in<br>
> cache) TCP_MISS/304 means TCP_REFRESH_UNMODIFIED.<br>
><br>
> So, this is HIT exactly.<br>
><br>
> I'm not saying - literally. And in fact. Correctly?<br>
><br>
><br>
><br>
> >>> Unfortunately, there are too many definitions of
a "hit".<br>
><br>
> >> There is no many definitions of hit. We are talking
about the caching<br>
> >> proxy, which is basically no different from all the
other caches, and<br>
> >> subject to the same rules.<br>
><br>
> > You are oversimplifying a complex subject matter. If
Squid delivers a<br>
> > single response comprising 1000 bytes from the cache and
10 bytes from<br>
> > the origin server, is that a hit or a miss? If Squid
delivers the entire<br>
> > response from the cache but spends 10 minutes talking to
the origin<br>
> > server about that object first, is that a hit or a miss?
Different<br>
> > people will give you different answers to those
questions.<br>
> 10 minutes a bit above TCP timeout and will be aborted, I
think. So,<br>
> Squid's write TCP_MISS_ABORTED in access.log. :)<br>
><br>
><br>
> > We have [poorly defined] byte hits, document hits,
revalidation hits,<br>
> > stale hits, partial hits, etc., etc.<br>
> What yes - yes. The documentation is the problem.<br>
><br>
><br>
><br>
> >> If the first access does not find an object in the
cache, it requests<br>
> >> from the network,<br>
><br>
> > yes<br>
><br>
> >> saves in the cache,<br>
><br>
> > or does not<br>
> Yes. May be or may be not. But in this case we are:<br>
> 1) Know about transaction history and we know the object(s)
in cache.<br>
> 2) Proxy can easy check it, right? Just swap in object from
disk in<br>
> memory. If this success, object in cache, so we can qualify
it as HIT.<br>
> Otherwise, exactly MISS.<br>
><br>
><br>
> >> and re-treatment or gets a hit,<br>
><br>
> > or does not<br>
><br>
> >> "the object is not changed." Dot.<br>
><br>
> > or the Squid-cached object did not change but the
client-cached object<br>
> > did. Or vice versa.<br>
> Client-cached object gives from Squid. They (ideally) must
not be the<br>
> different. Client cache and squid's cache operates like
chain, one is<br>
> source for another.<br>
><br>
><br>
><br>
> >> If the time in the cache<br>
> >> object lifetime expires, or a lifetime on the server
timed out - the<br>
> >> object is requested again and a miss is recorded.<br>
><br>
> > * Yes, if you define a miss as "contact with the origin
server".<br>
> I want to add: "contact with the origin server for get
content". Not for<br>
> revalidation purposes. If revalidation returns "Object not
changed" -<br>
> this is positive and must be qualified as HIT IMO.<br>
><br>
> > * No, if contact with the origin server is OK for a hit
as long as the<br>
> > server does not send the response _body_ back to Squid.<br>
> .... when revalidation true - i.e. object in shared cache not
stale,<br>
> this is HIT. We're not interested in client browser's cache
state. Only<br>
> shared cache matters.<br>
><br>
><br>
><br>
> >> if<br>
> >> the proxy responds to the client "has not changed",
it means, in fact,<br>
> >> that the client has a copy of the object<br>
><br>
> > Yes.<br>
><br>
> >> and a copy of the proxy object,<br>
><br>
> > The copy in the proxy cache may be different from the
copy in the client<br>
> > cache or may not exist at all.<br>
> Yes. If object not exists in proxy - this is proxy MISS. If
client cache<br>
> not contains object - client go to proxy and asks it about
object. Found<br>
> - excellent, for client this is MISS, for proxy - HIT. If
proxy also not<br>
> contains object - it will be MISS-MISS and loading object
from origin.<br>
><br>
><br>
><br>
><br>
> >> the proxy and responds to the client, performing
REFRESH that the object<br>
> >> did not change. What is this, if not hit?<br>
><br>
> > Assuming the proxy asked the origin server whether the
object in the<br>
> > client (or the proxy, depending on the circumstances)
cache is fresh,<br>
> > for many, it is<br>
><br>
> > * a [document] miss (because there was a potentially
very slow contact<br>
> > with the origin server) or<br>
> > * a [byte] hit (because the response body came from the
Squid cache and<br>
> > not from the origin server).<br>
><br>
> > Resisting the existence of different valid hit
definitions is futile<br>
> > IMO. State what _your_ definition is (be as precise as
possible; this<br>
> > may require several iterations) and then you may ask
whether a<br>
> > particular transaction is a hit.<br>
><br>
> > Alex.<br>
> I agree that there are a number of boundary cases. However,
in most<br>
> cases we are dealing with a relatively simple chain, which
should be<br>
> considered and, in my opinion. How is it to be regarded
revalidation<br>
> facilities and its results? If revalidation confirms that the
object is<br>
> not stale and not expired - it's a hit, is not it?<br>
><br>
> If revalidation fails - object stale/expired - everything is
clear and<br>
> there is nothing to discuss. Definitely miss.<br>
><br>
> Well, let's say we do not know and can not know about the
object in the<br>
> client cache. Assume also that we do not want to check -
whether this<br>
> object is in the cache proxy. Let us assume that we do not
want to spend<br>
> resources to figure out what happened to the object in the
future, in<br>
> client's browser, or on proxy's disk cache. Ok. Is, in this
case, would<br>
> not be more correct to write in log TCP_NONE/304?<br>
><br>
> In this case, we're talking directly - "We do not know, hit
it or not.<br>
> We only know that the object has not changed since the last<br>
> request/revalidation. We do not want to know, and you can
interpret it<br>
> any way you like".<br>
><br>
> It would be more correct, it seems to me, than just to say -<br>
> "TCP_MISS/304 - This is a cache miss, whatever it was not
really."<br>
><br>
> WBR, Yuri<br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJYAKv7AAoJENNXIZxhPexGSu4H/RWQb5rwEcT2bnxt50TdadOW
<br>
rAHLZ8ASdNDIRoumbXXqmbUTx4vIDTSp+Va77Sw1sKvcJgb/jZ7PdilyQSb60ZsS
<br>
IpBVMVbVz0gF7xe2Qqt6lB5Nl48Wmnernb/G47zdXnaJ9d8lZ/P5ed75rbzwXqDY
<br>
N7NKa9K2DBnC3PCCYehki2wnQIq7xObN3+D2wnlTSdaqnQFldE/jAmRaDT45A6Ay
<br>
awZe47loVM4zo0lTnzqHNlIgfG5ULRjbCHt/a/m4BiS6MPy9mos3yTrZ9xPA0RSX
<br>
UmqPTPGQ8gUXGm0YPRDIGT9b4pUZojuRk4ztpeqm6JdYJfF4yePpEnMsYvRWcN4=
<br>
=lkj2
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>