Estimating Bandwidth Requirements and Connection Speed (IIS 6.0)

Data traveling on a network is split into packets. In addition to the data that it carries, each packet includes about 20 bytes of header information and other network protocol information (this extra information is known as overhead). The amount of data in a packet is not fixed, and thus the ratio of overhead to data can vary. Most incoming HTTP requests are small. A typical request (for example, GET, including the TCP/IP overhead, consists of no more than a few hundred bytes as it travels across the network.

Overhead can become an important consideration when you are estimating your sites bandwidth requirements and deciding how fast a connection you need. If current usage is close to the limits of your connections capacity, an extra 20 percent for overhead might mean that you need the next faster type of connection.

Think of a server that displays static Hypertext Markup Language (HTML) text-only pages that average 5 kilobytes (KB), which is nearly equivalent to a full page of printed text. The server is connected to the Internet through a DS1/T1 line, which can transmit data at 1.536 megabits per second. Inherent overhead makes it impossible to use the full-rated T1 bandwidth of 1.544 megabits per second. For this 5-KB file, protocol overhead is significant, amounting to about 30 percent of the files size. For larger files, the overhead accounts for a smaller percentage of network traffic.

Table 6.3 shows the traffic generated by a typical request for a 5-KB page. Note that all the figures for overhead are estimates. The precise number of bytes sent varies with each request.

Table 6.3 Network Traffic Generated by a Request for a 5-KB Page
Traffic TypeBytes Sent

TCP connection

180 (approx.)

GET request

256 (approx.)

5-KB file


Protocol overhead

1,364 (approx.)



To calculate the number of bits for this 5-KB page, multiply the total number of bytes sent by 8 bits per byte:

6,920 8 = 55,360

As stated previously, a T1 line can transmit 1.536 megabits per second. Dividing bits per second by bits per page (1,536,000/55,360) indicates a maximum transmission rate of just under 28 pages per second. (Because modems add a start bit and a stop bit to each byte, the transmission rate through a modem is slower than the raw numbers appear to indicate.) For this small text-only page, Table 6.4 shows the relative speed for connections to several types of network interfaces and an estimated page delivery rate for each connection type.

Table 6.4 Relative Network Interface Speeds to Request a 5-KB Page
Connection TypeConnection Speed5-KB Pages Sent per Second

Dedicated PPP/SLIP via modem

28.8 kilobits per second (Kbps)

About half of 1 page

Frame Relay or fast modem

56 Kbps

Almost 1 page

Integrated Services Digital Network (ISDN)

128 Kbps

Just over 2 pages

Typical DSL

640 Kbps

Almost 11 pages


1.536 megabits per second (Mbps)

26 pages

10-megabit Ethernet

8 Mbps (best case)

(Up to) 136 pages


44.736 Mbps

760 pages


51.844 Mbps

880 pages

100-megabit Ethernet

80 Mbps (best case)

(Up to) 1,360 pages


155.532 Mbps

2,650 pages


622.128 Mbps

10,580 pages

1-gigabit/sec Ethernet

800 Mbps (best case)

(Up to) 13,600 pages

If you add a small graphic to the 5-KB page, the results are considerably different. An image, in the form of a .jpg file that appears on-screen as a 1-inch by 2-inch rectangle (the actual physical size depends on monitor settings), takes up about as much disk space as the original text file. Adding one such image file to each page nearly doubles the average page size and also the number of requests that are needed. This increased size reduces the number of pages that the server can send to the Internet on a DS1/T1 line to a maximum of about 15 pages per second, regardless of how fast the computer itself runs.

If a page contains several images, if the images are relatively large, or if the page contains multimedia content, the page can take much longer to download. You can often find simple solutions for improving download time, such as consolidating, removing, sizing down, or compressing images or converting images to a more compact graphics format. You might also connect to the network by using a faster interface (this change can improve performance for the server, but not necessarily for the client, as is discussed later in this section).

A site that serves primarily static HTML pages, especially pages with a simple structure, is likely to run out of network bandwidth before it runs out of processing power. In contrast, a site that performs a lot of dynamic page generation, or that acts as a transaction or database server, uses more processor cycles and can create bottlenecks in its processor, memory, disk, or network.

For more information about how to create more efficient Web pages, see Creating a More Efficient Web Site.

Browser Download Time

Up to this point, the bandwidth discussion has focused on the number of pages that a server can send in a specified amount of time. The second part of this discussion focuses on how long 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, which equals about 720 kilobits. If you ignore network latency, which is the amount of time required for a packet or signal to travel from one point on a network to another (latency typically adds a few seconds before any of the data arrives), and if everything is working perfectly, a 720-kilobit page downloads over a 28.8-Kbps connection in about 25 seconds. The download takes longer if any blocking or bottlenecks occur at the server, if the network is overloaded and slow, or if the users connection is slower than 28.8 Kbps (due to poor line quality, for example).

If the client computer has a higher bandwidth connection on an intranet, the download time is usually much shorter. If your Web site is on the Internet, however, you cannot count on a majority of users having faster connections.

Server-Side Request Processing

It takes about 52 connections at 28.8 Kbps to saturate a DS1/T1 line. Not accounting for delays (which are fairly typical), 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 all receive the 90-KB page in the 25 seconds calculated in the example.

If 100 clients simultaneously request that same page, however, the total number of bits to be transferred is 100 737,280 (720 kilobits). It takes between 47 and 48 seconds for that many bits to travel over a DS1/T1 line. When that many bits are involved, the network connection for the server, not the client, becomes the limiting factor.

A DS3/T3 line carries nearly 45 Mbps, about 30 times the capacity of 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, which is not the same as handling 2,000 simultaneous users: users occasionally stop to read or think, and typically spend only a small percentage of their time downloading, except while receiving streaming multimedia content. Because of this difference between users and connections, IIS 6.0 can support more users than the figures appear 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. Although 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 that a particular computer is performing.

These network performance differences scale linearly, and the scaling continues at higher data-transfer rates. Two DS3/T3 lines, for example, can serve approximately twice as many clients as one line can, provided that processor power is sufficient to keep up with user demand and no bottlenecks prevent your servers from operating at maximum processing power. Connecting to the network by using a faster interface often resolves any performance problems for the server, but not necessarily for the client, as is shown later in this section.

Perceived Delay, Acceptable Delay, and Site Performance

The amount of time in which a user perceives that a Web page appears, known as perceived delay, is not identical to the actual time that is required to fully display the page. If the first thing that the user sees when opening a page is a set of buttons that allow further navigation, the user might never know or care that the rest of the page takes longer than a minute to download. If, on the other hand, the page takes longer than a minute to download, and the navigation buttons do not appear until after the rest of the page, users might not wait for the download.

The length of an acceptable delay depends partly on the kind of information that the page provides, but no more than 30 seconds is usually considered acceptable. If the information is important, users are more likely, but still reluctant, to wait.

As a best practice, set minimum performance goals that specify the acceptable performance for each of your sites. For example, the managers of certain Microsoft e-commerce Internet sites test their site performance against the following minimum performance goals:

All pages must load within 10 seconds.

Average CPU usage for each server must be less than 70 percent.

Available memory must remain stable throughout the test period.

The site must maintain 10 customer checkouts per second.

© 2015 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies