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