[squid-dev] "TCP_MISS/304" can we describe it better?

[Amos Jeffries]

On 25/11/2015 1:19 p.m., Eliezer Croitoru wrote:
> I was wondering for a very long time.
> We have changed some of the access.log syntax and TCP_REFRESH_X was added.
> The TCP_MISS/304 is a bit miss leading when using the current squid
> access.log analytical tools.
> I think that it can be changed to something else since it's the right
> thing to do.
> It is a MISS since the origin was contacted and the full response from
> the server was spliced to the client and this is what the log should
> basically show.
> But admins just count "TCP_MISS" as a loss of HIT.
> I know they are not right and it's their way of understanding the logs
> wrongly but what should happen? Should it stay like this?
> Maybe the statistics tools are not up-to-date and this is not a squid
> issue.
> 
> Will it be a good idea to change it a bit or that "TCP_MISS/304" is a
> good one?

I suspect that should be TCP_IMS_MISS/304 or
TCP_CLIENT_REFRESH_MISS/304. But de-tangling it could be tricky. And
still will not solve the misunderstanding about "MISS" being in the name.


The problem is that the old code used a single enum value for each tag
name (as a whole) and each point updating the tag has to individually
calculate/estimate the entirety of the Squid processing that might have
been applied previously. Mistakes get made of course, or data needed to
decide properly is unknown, or two paths can reach the same set point.
Which is where that confusing output comes from.

I am wanting to make the LogTags a set of flags that different code
paths in Squid can set only the ones relevant to them. The log then
shows the final set, which is more accurately the code path that acted
on each request.


I got as far as moving the enum value into LogTags class and generating
the log entry from that class. But quick experiments about making "TCP_"
into a flag set by httpAccept() did not go well and its currently on hold.


Amos