Re: [RFC] new Squid status codes

On 03/07/2014 06:26 PM, Amos Jeffries wrote:

> TCP_TUNNEL
>
> - initially for CONNECT requests which Squid serves Direct. Also to be
> used in future if Squid accepts an Upgrade request for protocols like
> WebSockets
>
>
> TCP_RELAY
>
> - for requests which Squid serves without even considering the stored
> content. ie CONNECT relayed to cache_peer,

The above two definitions overlap. Please adjust to make them disjoint
if you think both are needed, keeping in mind that:

* Whether the request went direct or to a peer is already covered by the
"hierarchy code" field and should not be repeated in the "Squid result
code" (a.k.a. "Squid request status" and "Squid status code", depending
on where one looks) that you propose to expand.

* Request method such as CONNECT is also logged separately.

* The _MISS suffix is appropriate in both cases (using the current
definition of _MISS at http://wiki.squid-cache.org/SquidFaq/SquidLogs):
"The response object delivered was the network response object".

> requests forced to be MISS by "cache deny" or size limits, etc

> The key property being that these can never be a HIT so dont worry
> about it when trying to reduce MISS.

The two examples listed above seem to contradict the "key property"
intent stated right after them: If a MISS happens because of "cache deny
or size limits" one may actually want to "worry" about that transaction
when "trying to reduce MISS". For example, if I accidentally
misconfigure my Squid to "cache deny all", then I do want to analyze
transactions that missed because of that mistake. I do not want to
ignore those transaction, or I will never find the configuration bug.

> TCP_SHARED_*
>
> - to indicate collapsed forwarding on the request. Similar in principle
> to the TCP_CLIENT_* and TCP_REFRESH_* labels indicating client forced
> something to happen or revalidation took place.
> Mainly so people can measure the difference between reguler HIT/MISS
> and SHARED_HIT/MISS to determine if collapsed forwarding is worth it.

I agree that _SHARED_ (and adding sharing stats to the Cache Manager)
can be useful.

Please adjust the definition to clarify that _SHARED_ is going to be
used for all transactions that _started_ collapsed and not just those
that ended collapsed. For example. a request that was initially
collapsed but for which things did not work out (e.g., the master
transaction on which we collapsed got an uncachable response, and Squid
had to send that request to the origin server in isolation after all)
would most likely be logged as TCP_SHARED_MISS.

This SHARED tag will _not_ be used for the "initial" transaction that
others collapsed on, right? Again, it would be nice if the definition of
the _SHARED_ tag made that clear[er].

Thank you,

Alex.
Received on Sun Mar 09 2014 - 05:18:12 MDT