Re: [PATCH] Append _ABORTED or _TIMEDOUT suffixes to the squid result code field

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 18 Dec 2009 17:22:59 -0700

On 12/16/2009 01:24 PM, Amos Jeffries wrote:
> On Wed, 16 Dec 2009 19:54:45 +0200, Tsantilas Christos
> <chtsanti_at_users.sourceforge.net> wrote:
>> Amos Jeffries wrote:
>>> On Tue, 15 Dec 2009 21:56:08 +0200, Tsantilas Christos
>>> <chtsanti_at_users.sourceforge.net> wrote:
>>>> Hi all,
>>>> this patch append the _ABORTED or _TIMEDOUT suffixes to the
> action
>>>> access.log field.
>>>> The patch also exist for squid3.1 branch.
>>>>
>>>> The development sponsored by the Measurement Factory
>>>>
>>>>
>>>> Description:
>>>> When an HTTP connection with a client times out, append _TIMEDOUT
>>>> suffix to the Squid result code field in access.log.
>>>>
>>>> When an HTTP connection with the client is terminated prematurely by
>>>> Squid, append _ABORTED suffix to the result code field in access.log.
>>>> Premature connection termination may happen when, for example, I/O
>>>> errors or server side-problems force Squid to terminate the master
>>>> transaction and close all associated connections.
>>>>
>>>> The above changes make it possible to identify failed transactions
> even
>>>> when they have 200/200 received/send response status codes and a
>>>> "successful" Squid result code (e.g., TCP_MISS). This is important
> when
>>>> one does not want 1-hour "stuck" transactions for 15-byte GIFs to
>>>> significantly skew the mean response time statistics. Such
> transactions
>>>> eventually terminate due to, say, TCP errors, and the old code would
>>>> record huge response times for successfully-looking transactions.
>>>>
>>>> -
>>>> Christos
>> Hi Amos,
>>
>>> ? This seems like a situation that should never occur...
>> Not exactly.
>>
>>> Aborted and Timed Out transactions are 4xx/5xx errors from the client
>>> viewpoint right?
>> Maybe the transaction aborted or timed out after the headers (and some
>> body data) sent to the client.
>>
>
> Okay. I see now.
>
>>> or if they are really stale-on-error type pages we need to use
> MISS_STALE
>>> tags.
>> I am not sure. In any case it is not bad idea to know the reason (a
>> download aborted by the user for example, or timedout).
>
> If its only being appended after initial data send to the client, yes we
> can't use stale.

The feature is designed to work after the response headers have been
sent to the client. The feature does not benefit the client (which is
gone without a trace!). It is for the Squid operator who otherwise
suffers from 15-hour "successful" transactions getting logged and
skewing response time stats. In some real-world environments Squid
operators are penalized when Squid-logged response time is poor...

+1

Alex.
Received on Sat Dec 19 2009 - 00:20:24 MST

This archive was generated by hypermail 2.2.0 : Sat Dec 19 2009 - 12:00:02 MST