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

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 17 Dec 2009 09:24:26 +1300

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.

+1.

Amos
Received on Wed Dec 16 2009 - 20:24:34 MST

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