WWW FAQ: How fast does my net connection need to be?

How fast does my net connection need to be?

The following response to this very-frequently-asked-question was provided by Mike Meyer (mwm@contessa.phone.net).
The answer is "It depends." What it depends on is what kind of things you want to provide on your server. Here are some rules of thumb to use when deciding what kind of connection you need for your server.

The first rule of thumb is:

Don't worry about simultaneous access at first.

The first thing to do is make sure you've got enough bandwidth to send the objects you want to send in a reasonable time. That provides a lower bound on your line speed no matter what level of traffic you have.

The second rule of thumb is:

It should take at most 5 seconds to send a page.

The five second rule dates from command line days, when that was about how long people would wait before getting impatient with the system. It seems like a reasonable number to use now.

Since external images/audio/etc. are somewhat exceptional, allow more time for them. If you think they should have the same restrictions as above, buy the bandwidth your site will need to do so. However, the rule of thumb for external images/audio/etc is:

It should take at most 30 seconds to send an external file.

Given these rules, it's pretty straightforward to work out how large an HTML page and external files can be. At least, it's easy after you simplify things by ignoring IP overhead on the line, compression on modem lines, and anything that's less than 10% of the total (or even a little bit more than 10%).

The one simplification not to ignore is the multiple packet round-trips it takes to get data flowing through an HTTP channel. For modem lines, this is nearly a second for each HTTP connection, which is significant. For leased lines, it's more like .1 or .2 seconds, which is not significant.

On a 14.4 line assumed to be sending 1.4K bytes of data/second, with a 1 second startup, you get 4 * 1.4 or 5.6K of HTML. If you want to include a single inline image, that's 2 seconds of startup, so you're down to 3 * 1.4 or 4.2K of HTML + image. This means smallish HTML pages, and simple inline images. For external files, you get 29 * 1.4 or 40K, which is still a small image. If you have a 28.8 line, you get to double those figures; for a 9600 line, figure 2/3rds of that size.

On a 56K leased line assumed to be sending 5K/second, you get 25K of HTML, or mixed HTML/data. For external images, it's 150K. That should cover any reasonable HTML document, and small to medium external files. An MPEG movie might be a bit much.

With a T1 line assumed to be sending 150K/second, you get 750K of HTML, or 4.5 megabytes in an external file. Barring very large animations, this should be sufficient for anything you want to serve. More would be faster, but it also gets drastically more expensive.

Now that you know the minimum bandwidth to deliver a single object in a timely fashion, let's consider the total throughput of your site. The maximum throughput is about 118 megaybtes for a 14.4 modem line, 422 megabytes for a 56K line and 12 gigabytes for a T1 line.

Now look at the total bandwidth you are going to use. Don't forget that things other than the HTTP server will be using the line, and some of them may require more bandwidth than the server. If you need more than 100% of the available bandwidth, you have to buy more bandwidth. If you need more than 50% of that bandwidth, you should probably buy more bandwidth. If you need less than 10% of the bandwidth, you are fine.

To plug in some sample numbers, assume the average size of served objects is 20K. Rounding to the nearest hundred or thousand in all cases, we find that you are fine up to 600 access/day on a 14.4 line, and acceptable up to 3,000. For a 56K line, that's 2,300 and 11,500. For a T1, that's 63,000 and 315,000 access/day. If your document sizes are smaller - which is likely - multiply the numbers by the appropriate factor.

As a final note, people working well below the 50% limit for a T1 have encountered problems with the server platform. Usually, this is caused by the HTTP server software encountering some system limit. If you are working with servers in these ranges, you need to consider server platform as well.

World Wide Web FAQ