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 [EMAIL PROTECTED]
--
Please use Squid 2.7.STABLE1 or 3.0.STABLE6
--
Mark Nottingham [EMAIL PROTECTED]
--
Please use Squid 2.7.STABLE1 or 3.0.STABLE6
