Capacity Planning

Traffic

Servers send out pages in response to requests. In order to issue a request, a browser first establishes a Transmission Control Protocol (TCP) connection with the server, and then sends the request via that connection. Traffic, as the term applies to Web servers, is the resulting mixture of incoming requests and outgoing responses.

In general, traffic occurs in bursts and clumps that are only partly predictable. For example, many intranet sites have activity peaks at the beginning and end of the day, and around lunchtime; however, the exact size of these peaks will vary from day to day and, of course, the actual traffic load changes from moment to moment. Not surprisingly, there is a direct relationship between the amount of traffic and the network bandwidth needed. The more visitors your site has and the larger the pages it provides, the more network bandwidth your server requires.

To start with a simple example, imagine a server that displays static Hypertext Markup Language (HTML), text-only pages that average 5 kilobytes (KB) in size, which is about 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 (Mbps). Inherent overhead makes it impossible to use the full-rated T1 bandwidth of 1.544 Mbps. How many pages per second can the server send out under optimum conditions? To answer this question, it is necessary to look at the way the information travels between computers.

Data travelling on a network is split into packets. Each packet includes, in addition to the data it carries, roughly 20 bytes of header information and other network protocol information (all this extra information constitutes “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 http://www.microsoft.com/default.asp), including the Transmission Control Protocol/Internet Protocol (TCP/IP) overhead, consists of no more than a few hundred bytes as it travels across the network. For a 5-KB file like the one in this example, protocol overhead is significant, amounting to about 30 percent of the file’s size. For larger files, the overhead accounts for a smaller percentage of network traffic. Overhead can become an important consideration when you are estimating your site’s bandwidth requirements and deciding how fast a connection you’ll need. If you are close to the limits of your connection’s capacity, an extra 20 percent for overhead may mean that you will require the next fastest type of connection.

Table 4.1 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 4.1   Traffic Generated by a Request for a 5-KB Page

To find the number of bits, multiply the number of bytes sent by 8 bits per byte: 6,920 x 8 = 55,360. As stated previously, a T1 line can transmit 1.536 Mbps. Dividing bits per second by bits per page, 1,536,000/55,360, provides a maximum rate of just under 28 pages per second. (Because modems add a start bit and a stop bit to each byte, they are slower than the raw numbers appear to indicate.)

Table 4.2 illustrates the relative speeds of several network interface types, using the small, text-only page just mentioned. Numbers of pages transmitted at speeds faster than the standard Ethernet rate of 10 Mbps are rounded.

Table 4.2   Relative Network Interface Speed

If you add a small graphic to the 5-KB page, the results will be considerably different. An image, in the form of a .jpg file that appears on screen as, perhaps, a 1-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. This increased size reduces the number of page requests 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 there are several images on each page, if the images are relatively large, or if the pages contain other multimedia content, they will take considerably longer to download.

Given a page of moderate size and complexity, there are several ways to serve more pages per second:

• Remove some images from the page.
• Use smaller pictures if you currently send large ones, or compress the existing pictures (if they are already compressed, compress them further).
• Offer reduced-size images with links to larger ones, and let the user choose; use images of a file type that is inherently compact, such as a .gif or a .jpg file, to replace inherently large file types such as a .tif.
• Connect to the network by using a faster interface.

The last option resolves the issue at the server but not necessarily at the client, as will be shown later in this section.

A site that serves primarily static HTML pages, especially those with simple structure, is likely to run out of network bandwidth before it runs out of processing power. On the other hand, 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. There are no hard and fast rules that apply to all sites (one of the reasons why a comprehensive discussion of capacity planning is difficult), but the general relationship between bandwidth and CPU use for static versus dynamic pages is shown in the following figure.

See the following:

• Browser Download Time
• Other Services and Activities
• Considerations
• Caching and the Refresh Process
• Secure Sockets Layer

© 1997-1999 Microsoft Corporation. All rights reserved.