Re: header-to-header latency

Mark Nottingham wrote:
> hmm, you're thinking of connection stats as well as request stats?
>

I believe I am. Service-Times as well as Transfer-Times.
The HTTP level being a transfer time out of ?where?.
The comm layer running service times out of fde table.

In the pconn cases one service time, holding open a port, may cover
several requests.

> Right now, we've got:
>
> - client-side request start (http->start)
> - client-side response start (http->start + al->cache.h2h_msec)
> - client-side response done (http->start + al->cache.msec)

What Id look at is:
   http->times.start
   http->times.headers_done
   http->times.body_done

Same for writes at the response side.
   resp->...

>
> Logging the client-side request done point is an option, but it's of
> limited value, because most requests don't have a body, and as
> mentioned, the server can start sending the response before the request
> is done. Not against it, just don't see *much* value.

Think POSTS and uploads. It will impact on the total transfer time if
its ever non-zero.

>
> Is it also interesting to log server-side times, where appropriate?

May be useful for fastest-source calculations for the netdb. But the
comm-level service counters might be even better for that.

>
> On 06/06/2008, at 3:02 PM, Amos Jeffries wrote:
>
>> Mark Nottingham wrote:
>>> Agreed. There are some pathological cases that make things tricky
>>> (e.g., when the origin server starts sending a response before all of
>>> the request body is in), but I don't think we have to cover every case.
>>
>> I think designing some good timestamp capture points:
>> accept(), close(), and at set points of the req/resp.
>> should be enough to get every case. Permutations of stats can be
>> calculated from those points in the conn data when needed. Global
>> avereages etc after each request is done. The stats calculations don't
>> need to take place inside the critical request flow pathway at all.
>>
>> Amos
>>
>>> On 06/06/2008, at 2:21 PM, Amos Jeffries wrote:
>>>> Mark Nottingham wrote:
>>>>> A while back I filed:
>>>>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2345
>>>>> Any thoughts?
>>>>
>>>> I've not given it much thought. It sounds okay for a single step in
>>>> the right direction.
>>>>
>>>> What I'd like to see in the end is a clear presentation of all the
>>>> timing stat measures people want. In an easy to understand way.
>>>> Taking care of all the case permutations nicely.
>>>> Theres SYN/FIN for req and resp.
>>>> Header transfer duration, body transfer duration.
>>>> Req to Resp start and end durations (x4 there at least).
>>>> Others that haven't been mentioned in the last year??
>>>>
>>>> Docs and actions are unclear or confusing as to what is done and
>>>> what is displayed.
>>>>
>>>> Amos
>>>> --
>>>> Please use Squid 2.7.STABLE1 or 3.0.STABLE6
>>> --
>>> Mark Nottingham mnot_at_yahoo-inc.com
>>
>>
>> --
>> Please use Squid 2.7.STABLE1 or 3.0.STABLE6
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>

-- 
Please use Squid 2.7.STABLE1 or 3.0.STABLE6