Re: [RFC] new Squid status codes

Hi all,
  some of these values are really orthogonal in scope, so I'd love to
see them logged independently. Doing so would however change the
standard logging format, so this proposal is the second best choice
and I support it.

On Sun, Mar 9, 2014 at 6:18 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> 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.
>

-- 
    Francesco