Alex Rousskov wrote: > On 10/11/2017 04:52 AM, Amos Jeffries wrote: > > On 11/10/17 23:31, Victor Sudakov wrote: > >> Alex Rousskov wrote: > >>> To be sure that you are comparing apples to apples, you would need > >>> to log the X-Cache-Lookup response header to access.log (or enable > >>> ALL,2 debugging to see headers and/or collect packet traces). > > >> I don't think the freebsd-update cares about the X-Cache-Lookup > >> response, I'm just trying to save bandwidth and don't quite like the > >> result. > > > The X-Cache* headers are debug output from Squid. [...] > > MISS means a server was contacted for _something_ and HIT means local > > cache only was used. > > > Here is a more accurate description of the X-Cache and X-Cache-Lookup > header fields: > > X-Cache-Lookup:MISS means that Squid did not find the requested object > in its cache after parsing the client request, and X-Cache-Lookup:HIT > means that it did. In either case, the X-Cache-Lookup header field does > not tell us whether the server was contacted afterwards, although: > > * X-Cache-Lookup:MISS implies that the server contact is very likely > (but various errors and other corner cases may prevent any server > contact) and > > * X-Cache-Lookup:HIT implies that the server contact is less likely (but > client revalidation requests, stale cached responses, and other cases > make such contact possible). > > * X-Cache-Lookup:NONE means that there was no cache lookup at all. > (Listed here for completeness sake) > > > There is also X-Cache header field, but its value is just a mapping of > the final(?) status code to HIT or MISS categories. In Squid v3.5, the > HIT category is assigned to TCP_HIT, TCP_IMS_HIT, TCP_INM_HIT, > TCP_REFRESH_FAIL_OLD, TCP_REFRESH_UNMODIFIED, TCP_NEGATIVE_HIT, > TCP_MEM_HIT, and TCP_OFFLINE_HIT statuses. The rest are categorized as > MISSes. The X-Cache header field does not tell us whether the server was > contacted. Alex, thanks for the details. > > > > To avoid misunderstanding, I have provided this information to help you > triage why Squid revalidates so much in your use case, and not to > justify Squid behavior or blame the freebsd-update client. You now know > what the logged status and the header values mean. And you now know that > you have to look at the same transaction to analyze the combination of > logged values and headers. If you want to know _why_ Squid does what it > does, the information Amos and I have provided may help you dig deeper. > Once you know "why", you may be able to adjust Squid configuration (or > something else!) to reduce excessive revalidations. Now that I know that the revalidations (TCP_REFRESH_UNMODIFIEDs) don't fetch the actual bodies of the patches, I'm fine with them. > P.S. If the above is not documented on Squid wiki, please consider > documenting it. Thank you in advance. You suggest I do it? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
