1 The following is a demonstration of the weblatency.d script. 2 3 Here we run weblatency.d while a mozilla browser loads the 4 http://www.planetsolaris.org website. After the website was loaded, Ctrl-C 5 was hit to print the following report, 6 7 # weblatency.d 8 Tracing... Hit Ctrl-C to end. 9 ^C 10 HOST NUM 11 static.flickr.com 1 12 images.pegasosppc.com 1 13 www.planetsolaris.org 5 14 blogs.sun.com 7 15 16 HOST AVGTIME(ms) 17 static.flickr.com 65 18 blogs.sun.com 285 19 images.pegasosppc.com 491 20 www.planetsolaris.org 757 21 22 HOST MAXTIME(ms) 23 static.flickr.com 65 24 images.pegasosppc.com 491 25 blogs.sun.com 962 26 www.planetsolaris.org 3689 27 28 This gives us an understanding on which hosts were responsible for the 29 time endured while loading the website. It turns out that requests to 30 www.planetsolaris.org were the slowest, with a maximum time of 3.7 seconds 31 (probably the first request, which incurred a DNS lookup). 32 33 34 35 The following shows the same google lookup performed on a number of sites, 36 37 # weblatency.d 38 Tracing... Hit Ctrl-C to end. 39 ^C 40 HOST NUM 41 www.google.com.au 3 42 www.google.co.uk 3 43 www.google.com 3 44 www.google.co.nz 3 45 46 HOST AVGTIME(ms) 47 www.google.co.nz 450 48 www.google.com.au 502 49 www.google.com 567 50 www.google.co.uk 595 51 52 HOST MAXTIME(ms) 53 www.google.co.nz 544 54 www.google.com.au 559 55 www.google.com 744 56 www.google.co.uk 763 57 58 From the average time you would guess that I was running this from 59 New Zealand (the fastest), with times to the other hosts following suit 60 (Australia, USA, UK). I was actually running this from Australia - it's 61 interesting that the New Zealand server responded slightly faster. 62 63 64 65 66 Now several websites are loaded as a larger demonstration, 67 68 # weblatency.d 69 Tracing... Hit Ctrl-C to end. 70 ^C 71 HOST NUM 72 shop.abc.net.au 1 73 static.technorati.com 1 74 sunopensolaris.112.2o7.net 1 75 www.theage.com.au 1 76 ffxcam.smh.com.au 1 77 sunglobal.112.2o7.net 2 78 embed.technorati.com 2 79 technorati.com 2 80 fdimages.fairfax.com.au 4 81 blogs.sun.com 5 82 bugs.opensolaris.org 7 83 www.abc.net.au 34 84 www.smh.com.au 51 85 86 HOST AVGTIME(ms) 87 ffxcam.smh.com.au 0 88 sunglobal.112.2o7.net 0 89 www.abc.net.au 56 90 www.theage.com.au 64 91 shop.abc.net.au 65 92 www.smh.com.au 73 93 fdimages.fairfax.com.au 88 94 blogs.sun.com 130 95 bugs.opensolaris.org 162 96 static.technorati.com 350 97 technorati.com 352 98 embed.technorati.com 632 99 sunopensolaris.112.2o7.net 900 100 101 HOST MAXTIME(ms) 102 ffxcam.smh.com.au 0 103 sunglobal.112.2o7.net 0 104 www.theage.com.au 64 105 shop.abc.net.au 65 106 fdimages.fairfax.com.au 243 107 www.smh.com.au 244 108 blogs.sun.com 293 109 www.abc.net.au 315 110 static.technorati.com 350 111 technorati.com 356 112 bugs.opensolaris.org 560 113 sunopensolaris.112.2o7.net 900 114 embed.technorati.com 973 115 116 It's interesting that the most common host (www.smh.com.au, NUM == 51), 117 responded with a fast AVGTIME (73 ms). The reason for this may be due to 118 cacheing by my proxy server. Less common hosts such as embed.technorati.com 119 were quite slow. 120 121 122 123 The results from weblatency.d are interesting, but they don't point the 124 finger at one single cause for website latency. The value here is the response 125 time experienced by the client - which is a combination of many response 126 times (link speeds, proxy server, DNS server, web server). 127 128
Indexes created Mon Apr 20 00:23:12 UTC 2026