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

2015-11-25 Thread Eliezer Croitoru

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

Eliezer

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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev



___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev


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

2015-11-24 Thread Eliezer Croitoru

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?


Thanks,
Eliezer

* I got to the conclusion that Google+Youtube are not necessarily the 
bad guys!

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev