On 17/02/2012 2:29 p.m., E.S. Rosenberg wrote:
2012/2/17 Eliezer Croitoru:
it also depends on your ISP interception machines.
if they have a lot of users and less powerfull machines it will cause
slowdowns!
Yeah, we don't know what they have exactly, we hope it's good stuff
the problem is that when we don't know how much slowdown our systems
are introducing it is harder to complain to the ISP because they can
just put the blame by us even if that is not the case....
I guess I could stick wireshark on the WAN port connecting to the ISP,
the client making the request and possibly the proxies on the way make
sure their times are all in exact sync and see what the time
difference between a request being made internally, it going out,
coming back etc. is but that is very involved....
Squid retains and can log some of these useful metrics.
http://www.squid-cache.org/Doc/config/logformat/ has the particular
details for each of the below tags measurements when each starts and
stops...
%tr - time to get response to the client (what is normally logged)
%<tt - total time Squid spent communicating with server(s).
%<pt - time spent between sending request and receiving reply from the
upstream server. This will include all the ISP encoding overheaders for
the response.
%dt - DNS lookup lag time.
Squid request processing overheads is %tr-%<tt.
Squid connection setup overheads sending the request upstream is %<tt-%pt.
NP: In 3.1 and older the upstream connection time (%<tt) includes the
DNS (%dt) overheads. In recent 3.2 they are separate time segments.
HTH
Amos
