Re: header-to-header latency

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