Testing speed
Testing speed
How to test the speed of a host
Testing speed is not complicated, but it's not very simple either. I will talk about speed in the extended sense of the word. Basically speed is a measure on how fast can the data be transmitted between the visitor and the host's server.
Ping
You can test a first type of speed by pinging the server. That can be done at the MS-DOS prompt with a simple command: ping serverID, where server ID is either a domain name (e.g. C:\>ping yahoo.com), either an IP (e.g. C:\> ping 128.65.134.89).
The results should be similar to these:
Reply from 64.190.235.64: bytes=32 time=432ms TTL=45
Reply from 64.190.235.64: bytes=32 time=180ms TTL=45
Reply from 64.190.235.64: bytes=32 time=377ms TTL=46
Reply from 64.190.235.64: bytes=32 time=216ms TTL=45
Ping statistics for 64.190.235.64:
Packets: Sent=4 Received=4 Lost=0
(0% loss)
Approximate round trip times in milli-seconds:
Minimum = 180ms, Maximum = 432ms,
Average = 301 ms
To understand the figures, one must first understand how ping works. It's actually pretty basic. When you ping a computer you're sending a message: "Hey! yahoo.com! Are you there?" Then comes the answer: "Yes, I'm here!". By measuring the time it took yahoo.com to receive your message plus the time it took it's message to get to you (and by repeating this process a few times) one get a fair idea on how fast these computers can communicate.
It's all in the time measurement. A ping time of under 200ms is good good, 200 to 400ms is average and 400ms and above are poor ping times. However, poor ping times do not always indicate a problem. If you are pinging servers that are very far away (pinging a server located in USA from a computer located in Australia), poor ping times are normal even for a good connection.
The Loss % represents the percentage of packets (sent messages) that were "lost" (did not return within 1 second). Lost packets are, obviously, not good. However, some hosts disable the Internet Control Message Protocol (ICMP), so pings are not responded to. The reason they do this is to increase security for the server, although the whole idea of servers being more secure without ICMP has its fans and its fierce opponents as well.
Traceroute
Another way to measure speed is traceroute. Obviously this traces the route between the computer and the server. As the information goes from your computer to the server, it passes through a few routers. A traceroute will tell you how many routers are involved and information about the routers.
The MS-DOS command for traceroute is tracert serverID.
The results should be similar to these:
C:\WINDOWS>tracert www.mysitespace.com
Tracing route to www.mysitespace.com [64.68.191.111]
over a maximum of 30 hops:
1 119 ms 121 ms 120 ms sym0103723m01.bctel.net [207.102.1.251]
2 107 ms 114 ms 98 ms 207.102.34.249
3 113 ms 117 ms 123 ms 192.197.174.118
4 135 ms 122 ms 116 ms 166.48.13.245
5 134 ms 145 ms 159 ms core7.SanFrancisco.cw.net [204.70.4.93]
6 144 ms 142 ms 136 ms Hssi2-1-0.BR1.SCL1.Alter.Net [206.157.77.74]
7 145 ms 152 ms 147 ms 105.ATM3-0.XR1.SCL1.ALTER.NET [146.188.145.158]
8 138 ms 149 ms 146 ms 195.ATM2-0.TR1.SCL1.ALTER.NET [146.188.146.2]
9 189 ms 170 ms 209 ms 107.ATM6-0.TR1.NYC1.ALTER.NET [146.188.137.165]
10 187 ms 180 ms 180 ms 199.ATM7-0.XR1.BOS1.ALTER.NET [146.188.179.85]
11 194 ms 177 ms 185 ms 191.ATM8-0-0.GW1.BOS1.ALTER.NET [146.188.176.225]
12 196 ms 208 ms 179 ms NVC.customer.UU.NET [64.68.0.242]
13 197 ms 206 ms 207 ms www.mysitespace.com [64.68.191.111]
(Traceroute example quoted from http://www.mysitespace.com/howtoping.asp)
The numbers on the left are the so-called "hops". The number of hops that it takes to transmit a packet of data from computer A to computer B is the number of routers. In our example there are 13 hops.
As you can see, each response line gives you the HOP #, the round trip times for the 3 packets that were sent and host information (IP address and/or host name).
The roundtrip times for each hop are representative of the time it takes to go from the source to the host for that particular hop and back to the source.
Short times are a good sign. Also, a small number of hops is usually a good sign.
Traceroute is a good way to determine path but, just as ping, it should not be used as the last word when it comes to speed evaluation.
Download speed test
Arguably the ultimate test in terms of relative accuracy is the download speed test. To do that you should ask the host for a test download file. That's about the best way to judge speed. The goal is to find a host that has the capability of sending at least a few hundred kBytes/second. If you're on a dial-up connection you'll not be able to test this yourself. Read on and you'll find a solution to this particular problem.
Because the host might try to fool you by giving you a test file located on a fast, almost empty server, it might be even better if you'd contact a current customer and ask him/her to post a test file on his account.
The file should be big enough to allow you to see the speed stability over time. A 10-15 Mb file should be enough. Another important aspect is the time of the test. The best times are rush hours actually, when the servers are busy. These are in the morning when most people read their emails (8am on the east coast of the US) and dinner time. Take care to compensate for time differences as not all servers host American websites or address American audiences.
Always keep in mind that all results depend on location, ISP etc. This is why it's good to run a tracert from other computers located in other places of the world (where a significant part of your visitors might come from). Good places where you can do that are http://www.tracert.com/cgi-bin/trace.pl and http://www.traceroute.org.
I recommend you to ask the people at WebHostingTalk.com to help you with your
speed test. Usually there are people from all over the world there, so you will
get to have the host tested from various parts of the world, through different
networks, etc. Don't forget to post the URL of the test file! 
For as much as I know the right place for this kind of test requests is the "Other reviews" forum located at http://www.webhostingtalk.com/forumdisplay.php?s=&forumid=64.
Download speed vs. real website performance
The computing power required to push a simple file, even at very high transfer rates, is quite low, because all that needs to be done is to read the file and send it. Things change though when we're talking about a real website, especially one that makes heavy use of modern tools like databases and scripts. The needed computing power is much higher in this scenario and this can affect the speed at which the data is sent. Thus, it is good to find a real site hosted on that server (or by that host) and do a subjective and an objective speed test on it.
Going back to ping for a bit, just because you notice a ping difference of say 30ms, it doesn't mean that the diference in page loading time will be of 30ms. Usually a web page has to call for a number of files in order to look as it does. This includes images, css files, javascript files etc., and they're not all requested at the same time by the browser (as a courtesy to the server, to avoid unnecessary stress). Because these files are not downloaded simultaneously, the 30ms keeps adding to the total page load time with each new batch of requests. In this fashion, it is not unlikely to end up with a second or so of total difference just as a result of this latency.
Latency also has an effect on the maximum download speed possible, sometimes quite a significant one. It is thus not unlikely to have a page loading in 2 seconds when the ping is really low, and to have it load in 4+ seconds when latency is high.
Do all these things I told you about and you'll get a pretty good idea about
the speed of the host/server you're investigating. Hmm... tough word... "investigating".
It makes all these things sound soo... dangerous!