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

Eliezer Croitoru eliezer at ngtech.co.il
Wed Nov 25 08:05:14 UTC 2015

OK then, sounds good enough for now.
Do we have a bugzilla report on this one?


On 25/11/2015 02:59, Amos Jeffries wrote:
> 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
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev

More information about the squid-dev mailing list