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
Received on Fri Feb 17 2012 - 06:12:07 MST
This archive was generated by hypermail 2.2.0 : Fri Feb 17 2012 - 12:00:03 MST