Capacity Planning
Capacity Planning |
|
The number of pages a server can send is one half of the bandwidth equation. The other half is the time it takes a browser to download a page.
Consider how much time a browser needs to download a page that, including overhead, amounts to 90 KB or so—which equals about 720 kilobits. (Pages of this size are not at all unusual.) Ignoring latencies, which typically add a few seconds before any of the data arrives, it takes roughly 25 seconds to download 720 kilobits through a 28.8 kilobits per second (Kbps) connection if everything is working perfectly. On the other hand, if there’s any blocking or bottlenecking going on at the server, if the network is overloaded and slow, or if the user’s connection is slower than 28.8 Kbps (because of poor line quality, for example), the download will take longer.
If the client computer has a higher-bandwidth connection on an intranet, for example, the download time should be much shorter. If your Web site is on the Internet, however, you cannot count on a majority of users having faster connections until the next wave of connection technology becomes well-established. At the time of writing, a 56 Kbps modem standard has been adopted, but many (if not most) telephone lines are too noisy to allow full-speed connections with 56 Kbps modems. In addition, cable modem and Digital Subscriber Line (DSL) technologies are just beginning to appear in enough areas to compete in earnest. For this reason, it is not possible to tell which connection mode will take the upper hand or, for that matter, whether some other technology will appear and supersede both.
It takes about 52 connections at 28.8 Kbps to saturate a DS1/T1 line. If no more than 52 clients simultaneously request the page used in the preceding example, and if the server can keep up with the requests, the clients will all receive the page in the 25 seconds calculated in the example (again, ignoring the typical delays).
If 100 clients simultaneously request that same page, however, the total number of bits to be transferred will be 100 times 737,280 (720 kilobits). It takes between 47 and 48 seconds for that many bits to travel down a DS1/T1 line. At that point the server’s network connection is the limiting factor, not the client’s.
The figure below shows the relationship between concurrent connections and saturation for DS1/T1 and DS3/T3 lines, assuming all clients are using a modem transmission speed of 28.8 Kbps and are always connected. A DS3/T3 line carries nearly 45 Mbps, about 30 times as much capacity as a DS1/T1 line, and it takes more than 1,500 clients at 28.8 Kbps to saturate its bandwidth. Moreover, the increase in download time for each new client is much smaller on a DS3/T3 line. When there are 2,000 simultaneous 28.8 Kbps connections, for example, it still takes less than 33 seconds for a client to download the page.
This example assumes that the server is capable of performing the relevant processing and handling of 2,000 simultaneous connections. That’s not the same as handling 2,000 simultaneous users: Users occasionally stop to read or think, and typically spend only a modest percentage of their time downloading, except while receiving streaming multimedia content. Because of this difference between users and connections, the number of users that IIS 5.0 can support is larger than the figures would seem to indicate. A Web server on a DS1/T1 line can typically handle several hundred users connecting at 28.8 Kbps, and with a DS3/T3 line the number typically climbs to 5,000 or more. While these numbers are derived from actual servers, you can expect performance to vary with differing content types and user needs, and with the number and type of services being performed by a particular computer.
Essentially, the network performance differences shown here scale linearly, and the scaling continues at larger data-transfer rates. If you have two DS3/T3 lines, for example, you can serve approximately twice as many clients as you can with one, provided that you have enough processor power to keep up with user demand and that no bottlenecks prevent your servers from maximizing their processing power. For an example of such a bottleneck, see A Large-Site Case Study: microsoft.com later in this section.
It is important to remember that the amount of time a user perceives that a page appears is not identical to the (measurable) amount of time it takes for the page to fully display. If the first thing the user sees upon reaching a given page is a set of buttons allowing further navigation, the user may never know or care that the rest of the page takes over a minute to download. If, on the other hand, the page takes over a minute to download and the navigation buttons don’t appear until after the rest of the page, users probably won’t bother to wait unless they are forced to by circumstances. An acceptable delay depends to some extent on the kind of information provided by the page, but it is ordinarily no more than 30 seconds. If the information is important, your users will be more likely to wait longer for it, albeit reluctantly.