The following is a demonstration of the weblatency.d script.
Here we run weblatency.d while a mozilla browser loads the
http://www.planetsolaris.org website. After the website was loaded, Ctrl-C
was hit to print the following report,
Tracing... Hit Ctrl-C to end.
^C
HOST NUM
HOST AVGTIME(ms)
blogs.sun.com 285
HOST MAXTIME(ms)
blogs.sun.com 962
This gives us an understanding on which hosts were responsible for the
time endured while loading the website. It turns out that requests to
www.planetsolaris.org were the slowest, with a maximum time of 3.7 seconds
(probably the first request, which incurred a DNS lookup).
The following shows the same google lookup performed on a number of sites,
Tracing... Hit Ctrl-C to end.
^C
HOST NUM
HOST AVGTIME(ms)
www.google.co.nz 450
www.google.com 567
www.google.co.uk 595
HOST MAXTIME(ms)
www.google.co.nz 544
www.google.com 744
www.google.co.uk 763
From the average time you would guess that I was running this from
New Zealand (the fastest), with times to the other hosts following suit
(Australia, USA, UK). I was actually running this from Australia - it's
interesting that the New Zealand server responded slightly faster.
Now several websites are loaded as a larger demonstration,
Tracing... Hit Ctrl-C to end.
^C
HOST NUM
HOST AVGTIME(ms)
blogs.sun.com 130
technorati.com 352
HOST MAXTIME(ms)
www.smh.com.au 244
blogs.sun.com 293
www.abc.net.au 315
technorati.com 356
It's interesting that the most common host (www.smh.com.au, NUM == 51),
responded with a fast AVGTIME (73 ms). The reason for this may be due to
cacheing by my proxy server. Less common hosts such as embed.technorati.com
were quite slow.
The results from weblatency.d are interesting, but they don't point the
finger at one single cause for website latency. The value here is the response
time experienced by the client - which is a combination of many response
times (link speeds, proxy server, DNS server, web server).