Re: header-to-header latency

Picking this up...

To be truly complete, we need to measure all six of those stats on
both the client side and server side; some people will be interested
in how long it takes for Squid do to its magic. Doing so will burn a
little bit of memory.

I'm assuming everything except the client-side request start should be
a delta?

On 06/06/2008, at 9:03 PM, Amos Jeffries wrote:

> 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

--
Mark Nottingham       mnot_at_yahoo-inc.com