Re: header-to-header latency

hmm, you're thinking of connection stats as well as request stats?

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)

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.

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

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