MCSE Training Kit (Exam 70-226): (It Professional Series) Designing Highly Available Web Solutions with Microsoft Windows 2000 Server Technologies


This official MCSE Training Kit teaches IT professionals how to design mission-critical Web solutions using Windows 2000 Server technologies—as they prepare for MCP Exam 70-226, a core elective on the MCSE track. The kit balances high-level conceptual information with practical application: students learn through an integrated system of skill-building tutorials, case study examples, and self-assessment tools. Topics map directly to the objectives measured by the MCP exam, including planning and designing cluster ...
See more details below
Available through our Marketplace sellers.
Other sellers (Hardcover)
  • All (6) from $1.99   
  • New (2) from $39.49   
  • Used (4) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2015

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by
Sending request ...


This official MCSE Training Kit teaches IT professionals how to design mission-critical Web solutions using Windows 2000 Server technologies—as they prepare for MCP Exam 70-226, a core elective on the MCSE track. The kit balances high-level conceptual information with practical application: students learn through an integrated system of skill-building tutorials, case study examples, and self-assessment tools. Topics map directly to the objectives measured by the MCP exam, including planning and designing cluster and server architectures, network infrastructure, capacity requirements, security strategies, and application and service infrastructures. Business scenario examples help students apply the concepts they learn to real-world work situations. An economical alternative to classroom instruction, this MCSE Training Kit enables students to set their own pace and learn by doing!

Official Microsoft study guide for designing highly available Web solutions using Windows 2000 Server technologies

Provides self-paced, from-the-source information and practice with the skills measured by MCSE Exam 70-226—a core elective for Windows 2000 certification
Key Book Benefits:
* Offers in-depth instruction on how to plan and design Web infrastructure solutions in Windows 2000

* Prepares certification candidates for MCP Exam 70-226, Designing Highly Available Web Solutions with Microsoft Windows 2000 Server Technologies, a core elective on the MCSE track

* Case study scenarios help students apply the concepts they've learned to the job

* Features entire study guide on CD-ROM—for easy searches and reference
Read More Show Less

Product Details

  • ISBN-13: 9780735614253
  • Publisher: Microsoft Press
  • Publication date: 11/1/2001
  • Series: MCSE Training Kits Series
  • Edition description: Hardcover and CD-Rom
  • Pages: 510
  • Product dimensions: 7.60 (w) x 9.30 (h) x 1.67 (d)

Meet the Author

Founded in 1975, Microsoft (Nasdaq 'MSFT') is the worldwide leader in software for personal and business computing. The company offers a wide range of products and services designed to empower people through great software—any time, any place, and on any device.
Read More Show Less

Read an Excerpt

Chapter 1: Introduction to Designing Highly Available Web Solutions

Lesson 1: Introduction to Highly Available Web Solutions
Lesson 2: Determining System Availability
Lesson 3: Ensuring System Availability

About This Chapter

Protecting business uptime is an important challenge to many businesses. In some cases businesses try to have a Web site available 24 hours a day, 7 days a week. If they can't deliver a Web site that's highly responsive and always available, customers will find companies that can. Keeping a system up at all times is a high priority, especially in cases involving high financial stakes. To provide an infrastructure that meets these requirements, the system architect must design a platform that's available, reliable, and scalable. The platform should also provide ease of implementation, interoperability, and a short turnaround time to market. The front-end systems, back-end systems, and the networking infrastructure should work in conjunction with one another to provide high-performing, reliable, and scalable Web sites to online customers. This chapter introduces many of the concepts essential to the design of highly available Web sites. Additionally, this chapter provides information about designing these sites and determining an appropriate method of ensuring high availability. Many of the concepts introduced here are discussed in more detail in subsequent chapters. The information is presented here in order to provide a cohesive introduction to designing highly available Web solutions.

Before You Begin

To complete the lessons in this chapter, you must have
  • An understanding of basic design and administration concepts in Microsoft Windows 2000
  • An understanding of basic design and administration concepts of network infrastructures
  • A basic understanding of the concepts of high availability, fault tolerance, cluster technologies, redundant array of independent disks (RAID) implementations, load balancing, and storage area networks (SANs)

Lesson 1: Introduction to Highly Available Web Solutions

Because World Wide Web technologies are rapidly becoming the platform of choice for supporting enterprise-wide applications, the infrastructure required to develop and host applications has grown in scale and complexity. Server technology is particularly hard-pressed to keep up with the daily client demands for Web pages. One of the greatest concerns of vendors today is to make their products and services available 24 hours a day, 7 days a week. Providing this kind of service isn't only a business consideration, but also a matter of brand reputation. Businesses have spent millions of dollars to achieve the ideal of very high uptime. Even a small amount of downtime can cost a business a significant amount of revenue and damage its reputation. An outage can be caused by a variety of factors. The hardware, operating system, data storage, network, and management applications are some of the vulnerable areas that can lead to downtime. The system might not be resilient against disasters and faults in the system. To meet the demands of highly available Web sites, Microsoft Windows 2000 Advanced Server has been designed to address mission-critical needs. This lesson introduces you to Windows 2000 Advanced Server and provides an overview of some of the key terminology used in designing highly available Web solutions. In addition, this lesson provides an overview of the architectural changes that have occurred as networks have moved toward a Web computing model for business.
After this lesson, you will be able to
  • Describe which features in Windows 2000 Advanced Server support high availability and scalability
  • Define the key terminology used in designing highly available Web solutions
  • Describe the Web computing model for business
Estimated lesson time: 25 minutes

Windows 2000 Advanced Server

The Microsoft Windows 2000 Server family currently includes Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server. Windows 2000 Server offers core functionality appropriate to small and mediumsized organizations that have numerous workgroups and branch offices and that need essential services, including file, print, communications, infrastructure, and Web. Windows 2000 Advanced Server is designed to meet mission-critical needssuch as large data warehouses, online transaction processing (OLTP), messaging, e-commerce, and Web hosting services-for medium-sized and large organizations and for Internet service providers (ISPs). Datacenter Server includes all the functionality of Advanced Server, but provides greater reliability and availability. Datacenter Server is the best platform for large-scale line-of-business and back-end usage.

Windows 2000 Advanced Server evolved from Microsoft Windows NT Server 4, Enterprise Edition. It provides an integrated and comprehensive clustering infrastructure for high availability and scalability of applications and services, including main memory support up to 8 gigabytes (GB) on Intel Page Address Extension (PAE) systems. Designed for demanding enterprise applications, Advanced Server supports new systems with up to eight-way symmetric multiprocessing (SMP). SMP enables any one of the multiple processors in a computer to run any operating system or application threads simultaneously with the other processors in the system. Windows Advanced Server is well suited to database-intensive work and provides high availability server services and load balancing for excellent system and application availability.

Windows 2000 Advanced Server includes the full feature set of Windows 2000 Server and adds the high availability and scalability required for enterprise and larger departmental solutions. Windows 2000 Advanced Server includes the following functionality to support high availability:

  • Network Load Balancing (NLB)
  • The Cluster service, based on the Microsoft Cluster Server service in Windows NT Server 4, Enterprise Edition
  • Up to 8 GB main memory on Intel PAE systems
  • Up to eight-way SNIP

Note If you're uncertain about whether you have an Intel PAE computer system, contact your hardware vendor.

Key Terminology

In various types of documentation, the terminology used to describe specific characteristics of networks and Web sites often differs from one source to the next. In this section several key terms are defined to help you understand how specific terminology is used within this book.
Availability is a measure (from 0 to 100 percent) of the fault tolerance of a computer and its programs. The goal of a highly available computer is to run 24 hours a day, 7 days a week (100 percent availability), which means that applications and services are operational and usable by clients most of the time. Availability measures whether a particular service is functioning properly. For example, a service with an availability of 99.999 percent is available (functioning properly) for all but 5.3 minutes of unplanned downtime a year.

You can use many different methods to increase the availability of your Web site. They range from using servers with fault-tolerant components (such as hot swappable drives, RAID controllers, redundant network interfaces, and hot swappable system boards) to load-balanced clustered solutions (such as Cisco Local Directors or Microsoft Application Center Server 2000) to failover clustered solutions (such as the Cluster service or Veritas Cluster Server). In the case of a completely redundant computer system, the software model for using the hardware is one in which the primary computer runs the application while the other computer idles, acting as a standby in case the primary system fails. The main drawbacks to redundant systems are increased hardware costs with no improvement in system throughput, and, in some cases, no protection from application failure.

You can make front-end systems at the Web tier highly available through the use of clustered servers that provide a single virtual Internet Protocol (IP) address to their clients. You can use load balancing to distribute the load across the clones. Building a failuredetection process into the load-balancing system increases the service's availability. A clone that's no longer offering a service can be automatically removed from the load-balanced set while the remaining clones continue to offer the service.

You can make back-end systems highly available through the use of failover clustering. In failover clustering, if one node fails, the other node takes ownership of its resources. Failover clustering assumes that an application can resume on another computer that's been given access to the failed system disk subsystem. The primary node will automatically failover to the secondary node when a clustered application, the operating system, or a hardware component of the primary node fails. The secondary node, which should be a replica of the primary node, must have access to the same data storage....

Read More Show Less

Table of Contents

About This Book
Ch. 1 Introduction to Designing Highly Analysis Web Solutions 1
Ch. 2 Network Infrastructure 25
Ch. 3 Server Configurations 81
Ch. 4 Microsoft Windows 2000 Cluster Service 107
Ch. 5 Network Load Balancing (NLB) 147
Ch. 6 Microsoft Application Center 2000 187
Ch. 7 Capacity Planning 229
Ch. 8 Directory Services 275
Ch. 9 Application Integration 301
Ch. 10 Network Security 339
Ch. 11 Systems Monitoring and Disaster Recovery 381
App.: Questions and Answers 419
Glossary 465
Index 493
Read More Show Less

First Chapter

Chapter 7.
Capacity Planning
    • About This Chapter
    • Before You Begin
  • Lesson 1: Introduction to Capacity Planning
    • Traffic
    • Performance
    • Availability
    • Scalability
    • Lesson Summary
  • Lesson 2: Calculating User Costs
    • Overview of Calculating Costs
    • Calculating Cost Per User
    • Lesson Summary
  • Activity 7.1: Calculating CPU Usage
  • Activity 7.2: Calculating Network Bandwidth
  • Lesson 3: Planning Network Capacity
    • The Planning Process
    • Making a Decision
    • Lesson Summary
  • Lab 7.1: Planning CPU and Bandwidth Capacity
    • Before You Begin
    • Exercise 1: Identifying the User Base
    • Exercise 2: Determining CPU Requirements
    • Exercise 3: Determining Bandwidth Capacity
  • Review

Chapter 7   Capacity Planning

About This Chapter

When planning to implement a Web site, you must ensure that the network and its components can handle the number of users who will access it. Capacity planning—the process of measuring a Web site's ability to deliver content to its visitors at an acceptable speed—is essential to making sure that your system will perform adequately when a peak number of users are accessing the applications and services in your network. Slow performance and unavailable service can encourage your customers to try other Web sites—and perhaps never return to yours. As a result, you must try to plan, to the best of your ability, for the greatest number of users who will try to use your site at the same time, and from that determination, you must ensure that your network's hardware and software have sufficient capacity to meet anticipated demand. In this chapter you'll be introduced to a number of issues related to capacity planning. You'll also learn how to estimate user costs, such as CPU and memory usage, and how to plan your network's capacity requirements.

Before You Begin

To complete the lessons in this chapter, you must have

  • Experience administering Microsoft Windows 2000 Server and designing Windows 2000 networks
  • Experience planning network capacity

Lesson 1: Introduction to Capacity Planning

The goal of any Web site is to present users with a high-quality experience. When users face slow response times, timeouts and errors, and broken links, they become frustrated and often turn to other sites to find what they're looking for. To prevent this, you must provide an infrastructure that can handle not only average levels of demand but also peak levels and beyond. Capacity planning makes it possible to calculate how much hardware is necessary to meet users' demands. These calculations allow you to identify bottlenecks in the network design that can cause performance degradation and lead to poor user experiences. You can then modify the design or implement the changes needed to eliminate these bottlenecks. However, before you can plan your network's capacity requirements, you must be familiar with several basic concepts that are important to your understanding of the issues involved in capacity planning. This lesson introduces you to these concepts by describing how network traffic, performance, availability, and scalability are all factors in the capacity planning process.

After this lesson, you will be able to
  • Identify and describe issues that are relevant to capacity planning

Estimated lesson time: 25 minutes


When a browser requests information from a Web server, it first establishes a Transmission Control Protocol (TCP) connection with the server. The browser then sends the request through the connection, and the server sends out pages in response to the requests. This interchange of incoming requests and outgoing responses is referred to as traffic.

Traffic is only partly predictable. It tends to occur in bursts and clumps. For example, many sites might experience activity peaks at the beginning and end of the workday but have lower levels of activity in the middle of the day. In addition, the size of these peaks might vary from day to day. Not surprisingly, a direct relationship exists between the amount of traffic and the network bandwidth necessary to support that traffic. The more visitors to your site and the larger the pages provided by the server, the more network bandwidth that's required.

Suppose your Web site is connected to the Internet through a DS1/T1 line, which can transmit data at 1.536 megabits per second (Mbps). The Web server displays static Hypertext Markup Language (HTML), text-only pages that average 5 kilobytes (KB) per page. Each transmission carries with it a packet overhead that contains header information. For a 5-KB file, the overhead might average 30 percent of the file's size. For larger files, the overhead accounts for a smaller percentage of network traffic.

Figure 7.1 illustrates how a load is distributed over a T1 line for a 5-KB page request.

Figure 7.1  Transmitting a 5-KB page over a T1 line (Image unavailable)

Table 7.1 shows the traffic generated by a typical request for a 5-KB page. Many of the figures are only estimates. The exact number of bytes sent varies for each request.

Table 7.1  Traffic Generated by 5-KB Page

Traffic Type Bytes Sent
TCP connection 180 (approximately)
GET request 256 (approximately)
5-KB file 5,120
Protocol overhead 1,364 (approximately)
TOTAL 6,920 (55,360 bits)

The standard transmission rate for a T1 line is 1.544 Mbps. Under normal conditions, the available bandwidth is 1.536 Mbps, or 1,536,000 bits per second. (The available bandwidth is reduced because 8,000 bits is required for framing the bit stream.) To determine the maximum rate of pages per second that your network can support, you should divide the bits per second of the T1 line by the bits generated for a 5-KB page request. In this case you'd divide 1,536,000 by 55,360, which comes to a maximum transmission rate of 27.7 pages per second.

Of course, if you add graphics to your files, the results will be considerably different. In addition, if each page has several images, if the images are relatively large, or if the pages contain other multimedia content, download time will be much longer.

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're 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's inherently compact, such as a .gif or a .jpg file, to replace inherently large file types, such as a .tif file.
  • Connect to the network by using a faster interface or by using multiple interfaces. Note that this option resolves the issue at the server but not necessarily at the client.

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.

Client-Side Network Capacity

Server-side network capacity isn't the only factor to consider when determining bandwidth limitations. The client computer is limited by its connection to the Internet. It can take a considerable amount of time, relative to a server's output, for a browser to download a page.

Suppose you want to download a page that, including overhead, totals about 90 KB (about 720 kilobits). 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. Figure 7.2 illustrates the process of downloading the 90-KB page.

If any blocking or bottlenecking is going on at the server, if the network is overloaded and slow, or if the user's connection is slower than 28.8 Kbps, the download will take longer. For example, a poor phone line connection can affect the download rate.

If the client computer has a higher-bandwidth connection on an intranet, the download time should be much shorter. If your Web site is on the Internet, however, you can't count on a majority of users having faster connections until the next wave of connection technology becomes well established. Although many users now use 56 Kbps modems, many (if not most) telephone lines are too noisy to allow full-speed connections with 56 Kbps modems. In some areas cable modem and Digital Subscriber Line (DSL) technologies are being used extensively. For this reason, it's impossible to tell which connection mode users will use to connect to your site.

Figure 7.2  Downloading a 90-KB page (including overhead) through a 28.8 Kbps modem (Image unavailable)

Table 7.2 lists the relative speeds of several network interface types, based on a 5-KB text-only page. Numbers of pages transmitted at speeds faster than the standard Ethernet rate of 10 Mbps are rounded.

Table 7.2  Network Interface Speeds

Connection Type Connection Speed 5-KB Pages Sent per Second
Dedicated Point-to-Point Protocol/ Serial Line Internet Protocol (PPP/SLIP) using a modem 28.8 Kbps Roughly 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 digital subscriber line (DSL) 640 Kbps Almost 11 pages
Digital signal level 1 (DS1)/T1 1.536 Mbps 26 pages
10-Mb Ethernet 8 Mbps (best case) (Up to) 136 pages
Digital signal level 3 (DS3)/T3 44.736 Mbps 760 pages
Optical carrier 1 (OC1) 51.844 Mbps 880 pages
100-Mb Ethernet 80 Mbps (best case) (Up to) 1,360 pages
Optical carrier 3 (OC3) 155.532 Mbps 2,650 pages
Optical carrier 12 (OC12) 622.128 Mbps 10,580 pages
1-gigabit-per-second (Gbps) Ethernet 800 Mbps (best case) (Up to) 13,600 pages

Server-Side Network Capacity

It takes about 52 connections at 28.8 Kbps to saturate a DS1/T1 line. If no more than 52 clients simultaneously request a 90-KB page (including overhead) and if the server can keep up with the requests, the clients will all receive the page in 25 seconds (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 720,000 (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, not the client's, is the limiting factor.

Figure 7.3 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.

Figure 7.3  Download time versus server network bandwidth (Image unavailable)

The data shown in Figure 7.3 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 Internet Information Server (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.


The performance of Web applications is critical in determining the site's capacity. Testing is the only way to find out a Web application's capacity and performance. The Web Capacity Analysis Tool (WCAT) and Web Application Stress Tool (WAST) utilities (included on the Windows 2000 Server Resource Kit companion CD) are useful testing tools. Before writing an application, however, it's useful to have a sense of the performance capabilities of different Web application types. In IIS 5.0, Internet Server Application Programming Interface (ISAPI) applications running as in­process dynamic-link libraries (DLLs) generally offer the best performance. After that, the next best solution is Active Server Pages (ASP) applications, followed by Common Gateway Interface (CGI) applications.

For most applications, the recommendation is to use scripting in ASP pages to call server­side components. This strategy offers performance comparable to ISAPI performance, with the advantage of more rapid development time and easier maintenance.

Table 7.3 shows the results of performance tests run on a beta version of IIS 5.0. The application ran on uniprocessor and multiprocessor kernels for Secure Sockets Layer (SSL) connections and non-SSL connections. The hardware and software used for the tests are described on the next page.

Table 7.3   Performance Testing of IIS 5.0

Test Non-SSL 1 CPU Non-SSL 2 CPUs Non-SSL 4 CPUs SSL 1 CPU SSL 2 CPUs SSL 4 CPUs
ISAPI in-process 517 723 953 50 79 113
ISAPI out-of-process 224 244 283 48 76 95
CGI 46 59 75 29 33 42
Static file (FILE8K.TXT) 1,109 1,748 2,242 48 80 108
ASP in-process 60 107 153 38 59 83
ASP out-of-process 50 82 109 28 43 56

The figures given in Table 7.3 are the actual numbers of pages per second that were served during testing. Each test repeatedly fetched the same 8-KB file. Note that different computer types will provide different performance for the same test. In addition, the performance of different application types depends greatly on the application's task. For these tests the task was a relatively light load, so the differences among the various methods are maximized. Heavier tasks result in performance differences that are smaller than those reflected in the table.

The following hardware and software were used for the test:

  • The servers were Compaq Proliant 6500 (4 × Pentium Pro 200 MHz) with 512 MB of 60 nanoseconds (ns) RAM.
  • The clients were Gateway Pentium II machines, 350 MHz with 64 MB RAM.
  • The network was configured as follows:
    • Clients used one Intel Pro100+ 10/100 MB network adapter card.
    • The server used four Intel Pro100+ 10/100 MB network adapter cards.
    • Four separate networks were created to distribute the workload evenly for the server, with four clients per network. Two Cisco Catalyst 2900 switches were used, each having two Virtual LANs (VLANs) programmed.
  • The following software was used:
    • The server was configured with Windows 2000 Advanced Server and IIS 5.
    • The clients were configured with Windows 2000 Professional.
    • WAST was used to test the site.

These tests were conducted with out-of-the-box computers and programs. No additional registry changes or performance enhancements were administered.


Some sites can afford to fail or go offline; others can't. Many financial institutions, for example, require 99.999 percent availability or better. Site availability takes two forms: the site needing to remain online if one of its servers crashes and the site needing to remain online while information is being updated or backed up. As discussed in earlier chapters, you can achieve site availability through the use of redundant services, components, and network connections. For example, services can be made redundant through the use of Network Load Balancing (NLB) and the Cluster service.

Availability is an important consideration when planning your network's capacity requirements. You must first determine what type of availability you're trying to achieve. How many 9s are you trying to adhere to? Although 99.999 percent might be ideal, it might not be realistic—or necessary—for your organization. In other words, how much can your organization afford to spend to ensure that your network can always meet your peak capacity requirements?

You must determine whether the problems caused by your site's unavailability offset the expense of trying to keep it online. If you require 99.999 percent availability or better, then you must ensure that users won't be prevented from accessing your resources because your site has reached its capacity. If, on the other hand, you need to achieve only 99 percent availability or less, you might be less concerned with your site occasionally being unavailable to users because your site has reached its capacity limits, particularly if peak capacity is rare.


The scalability of your site is a primary consideration when you're ready to upgrade it to improve availability, increase the number of concurrent users, or decrease its latency for faster response times. A site's scalability goes hand in hand with its availability. Upgrading your site shouldn't lead to unplanned or unnecessary downtime. You should take two types of scaling into consideration when upgrading your site: scaling up and scaling out. Scalability is discussed in more detail in Lesson 3: "Planning Network Capacity."

Lesson Summary

Four factors are important to capacity planning: network traffic, performance, availability, and scalability. Traffic is the interchange of incoming requests and outgoing responses between two computers. Traffic is often unpredictable and occurs in bursts and clumps. To determine the maximum rate of pages per second that your network can support, you should divide the bits per second of the network connection (such as a T1 line) by the bits generated for the page request. A server's capacity isn't the only factor to consider when determining bandwidth limitations. The client computer is limited by its connection to the Internet. The performance of Web applications is critical in determining the site's capacity. Testing is the only way to find out the capacity and performance of a Web application. You can use the WCAT and WAST utilities to test an application. Different computer types will provide different performance for the same test, and the performance of different application types depends greatly on the application's task. Availability is an important consideration when planning your network's capacity requirements. You must determine whether the problems caused by your site's unavailability offset the expense of trying to keep it online. The scalability of your site is a primary consideration when you're ready to upgrade it in order to improve availability, increase the number of concurrent users, or decrease its latency for faster response times.

Lesson 2: Calculating User Costs

You can determine the appropriate capacity level for your Web site by measuring the number of visitors the site receives and the demand each user places on the server and then calculating the computing resources (CPU, RAM, disk space, and network bandwidth) that are necessary to support current and future usage levels. Site capacity is determined by the number of users, server capacity, configuration of hardware and software, and site content. As the site attracts more users, capacity must increase or users will experience performance degradation. By upgrading the computing infrastructure, you can increase the site's capacity, thereby allowing more users, more complex content, or a combination of the two. However, before you can plan your network's capacity requirements or determine an upgrade strategy, you must be able to calculate the costs imposed on the system by each user. This lesson explains how you can calculate those costs so that you can plan your network's capacity.

After this lesson, you will be able to
  • Calculate costs of CPU, memory, and disk usage
  • Calculate network bandwidth

Estimated lesson time: 30 minutes

Overview of Calculating Costs

At its most basic level, capacity planning can be expressed as a simple equation:

Number of supported users = hardware capacity ÷ load on hardware per user

In this equation, number of supported users refers to concurrent users and hardware capacity refers to both server and network capacity.

Generally, capacity planning is based on two concepts:

  • You can decrease the load that each user puts on the hardware, or you can increase the number of supported users. This is done through planning, programming, and configuring the site content to make more efficient use of computing resources.
  • You can configure the site infrastructure to increase hardware capacity, or you can increase the number of supported users. Options include scaling the hardware out (adding more servers) or up (upgrading the existing servers).

If you want to increase the complexity of the site's content, thereby increasing the load on hardware per user, and still maintain the number of supported users, then you must increase the site's hardware capacity. This supports either the scaling up or scaling out decision. However, if you want to be able to support more users, you must either simplify the site content or increase hardware capacity. This supports the decision to decrease the load on hardware per user.

Operational Parameters

The primary benchmark to use when determining whether a Web site is operating at an acceptable level is latency, or how long a user has to wait for a page to load once a request has been made. Note that although some servers may be capable of handing every request they receive, the load on the servers might create unacceptable wait times, requiring a better performing solution if the site is to operate efficiently and at a level of service users are willing to accept.

In general, static content such as normal HTML pages and graphics don't contribute to server latency nearly as much as dynamic content such as ASP pages or other content that requires database lookups. Even when a Web server is able to deliver a large number of ASP pages per second, the turnaround time per ASP page can be unacceptable. The chart shown in Figure 7.4 illustrates the latency experienced by users of a four-processor Web server as the number of users and ASP requests increases.

Figure 7.4  ASP pages per second versus latency (Image unavailable)

This site's capacity is between 700 and 800 concurrent shoppers per second. Note that the wait time rises dramatically as the number of users exceeds 800. This is unacceptable. This server's performance peaks at just over 16 ASP requests per second. At this point the users are waiting roughly 16 seconds for their pages, due to extensive context switching.

Calculating Cost Per User

You should take five steps to determine your cost per user: analyzing the typical user, calculating CPU cost, calculating memory cost, calculating disk cost, and calculating network cost. In order to illustrate each of these steps, a fictitious company—Northwind Traders—is used to demonstrate how user costs are calculated. Sample test results, used to simulate capacity testing through such means as the WAST test utility, are provided as needed, along with any additional data necessary to calculate cost per user.

Calculating user costs is an involved and detailed process. The purpose of this lesson is merely to give you an overview of that process and try to illustrate, through the use of examples, how the basic calculations are made. It's strongly recommended that you study additional sources so that you have a complete understanding of the process of calculating costs.

Analyzing the Typical User

The first step you need to take in calculating user costs is to determine how the typical user will use your site. By determining the operations that users perform and how often they perform them, you can estimate how much demand a user places on the system. For the purpose of this lesson, the term operation refers to all files that are included in the processing of the primary page. This can include graphic files, ASP include files, or other supporting files. To the user it seems like a single operation or page.

To do this, you must compile a user profile by analyzing the site's usage log files. The more accurate the user profile, the more accurate capacity planning will be. For this reason, it's better to use logs gathered over a long period of time (at least a week) to obtain accurate averages.

You should gather the following types of data:

  • The number of visitors the site receives
  • The number of hits each page receives
  • The rate at which transactions take place

You can use the number of visits to each page to profile typical operations for the site. Table 7.4 provides a profile report for a typical user of the Northwind Traders Web site. The table contains the simulated results gathered from test data.

Table 7.4  Typical User Profile for Northwind Traders Web Site

Operation Operations per Session Operations per Second (Frequency) Percent of Total
Add Item 0.24 0.00033 2.00%
Add+Checkout 0.02 0.00003 0.17%
Add+Clearitems 0.04 0.00006 0.33%
Basket 0.75 0.00104 6.25%
Default 1.00 0.00139 8.33%
Listing 2.50 0.00347 20.83%
Lookup 0.75 0.00104 6.25%
New 0.25 0.00035 2.08%
Product 4.20 0.00583 35.00%
Search 1.25 0.00174 10.42%
Welcome 1.00 0.00139 8.33%
TOTAL 12.0 0.01667 99.99%

This table shows the 11 operations that account for nearly 100 percent of the hits received by the entire site. On big sites, the load might be distributed over a larger set of operations. As a rule, you should generate a report that lists the pages or operations responsible for at least 90 percent of the site's total hit count.

Calculating CPU Cost

In a typical environment, the Web servers place more demand on the CPU than the data servers do. As a result, this example focuses on measuring the CPU capacity on the Web servers. However, you should perform these calculations on all types of servers in the site where CPU power might become a bottleneck.

Page requests per second and CPU use grow with the number of users. However, when CPU use reaches the maximum, it results in lower page requests per second. Therefore, the number of page requests processed per second at the point at which CPU use reaches 100 percent is the maximum.

Before you can calculate an operation's CPU cost, you need to know the following information:

  • Page throughput (requests per second)
  • CPU utilization (percentage of available CPU at optimum page throughput)
  • Number of times a page is used per operation (request per operation)
  • Upper bound of your CPU

You can calculate an operation's cost by multiplying the number of pages by the cost per page. This calculation is based on megacycles (MC). The MC is a unit of processor work; 1 MC is equal to 1 million CPU cycles. As a unit of measure, the MC is useful for comparing performance between processors because it's hardware independent. For example, a dual-processor 400 MHz Pentium II has a total capacity of 800 MC.

The first step in calculating the CPU cost per user is to calculate the CPU cost per operation (in MC). You can use the following formula to calculate the cost:

CPU usage ÷ Requests per second × Requests per operation = Cost per operation

To calculate the CPU usage, use the following formula:

CPU utilization × Number of CPUs × Speed of the CPUs (in MHz) = CPU usage

For example, suppose your computer is a dual-processor 400 MHz Pentium II. A browse operation results in 11.5 requests per second with CPU utilization of 84.10 percent. There are two page requests per operation. You'd first determine the CPU usage, as follows:

0.8410 × 2 × 400 = 672.8

You can then determine the CPU usage per operation, as follows:

672.8 ÷ 11.5 × 2 = 117.01 MC

Table 7.5 provides the CPU cost for each of the main operations of the Northwind Traders Web site. The figures are based on a dual-processor 400 MHz Pentium II.

Table 7.5  CPU Costs per Operation

Operation CPU Utilization Requests/Sec Requests per Operation CPU Cost per Operation (MC)
Add Item 96.98% 23.31 2 66.57
Add+Checkout 94.31% 18.48 7 285.79
Add+Clearitems 95.86% 22.29 4 137.62
Basket 91.73% 16.81 1 43.65
Default 98.01% 102.22 1 7.67
Listing 91.87% 21.49 1 34.20
Lookup 99.52% 75.40 2 21.19
New 96.61% 65.78 2 23.50
Product 94.81% 18.23 1 41.61
Search 95.11% 37.95 2 40.10
Welcome 96.97% 148.93 1 5.21

Once you've determined each operation's CPU cost, you can calculate the CPU cost per user by using the following formula:

Cost per operation × Operations per second = Cost per user

For example, the cost of an Add Item operation is 66.57 MC. Based on the profile of the typical user, you know that the number of operations per second is 0.00033. So you'd use the following calculation to determine the cost per typical user:

66.57 × 0.00033 = 0.0222 MC

Table 7.6 shows the CPU usage for the typical user for each operation.

Table 7.6  CPU Costs per User

Operation CPU Cost per Operation (MC) Operations per Second (frequency) CPU Usage per User (MC)
Add Item 66.57 0.00033 0.0220
Add+Checkout 285.79 0.00006 0.0171
Add+Clearitems 137.62 0.00104 0.1431
Basket 43.65 0.00003 0.0013
Default 7.67 0.00139 0.0107
Listing 34.20 0.00347 0.1187
Lookup 21.19 0.00104 0.0220
New 23.50 0.00035 0.0082
Product 41.61 0.00583 0.2426
Search 40.10 0.00174 0.0698
Welcome 5.21 0.00139 0.0072
TOTAL     0.6627

The total indicates that the cost of the total user profile is 0.6627 MC per user. This number reflects the cost of an average user performing the operations described by the user profile. You can use this number to estimate the site's capacity, based on the assumed user profile.

For example, suppose the upper bound for your dual-processor 400 MHz Pentium II is 526 MHz. The cost of 100 concurrent users is 100 × 0.6627 = 66.27 MC. The cost for 790 users is 523.53 MC. Both numbers of users are within the limits of the upper bound. However, more than 790 concurrent users would exceed your CPU capacity.

If you can't upgrade or add processors to increase your CPU capacity, you can take two main steps to improve CPU efficiency:

  • Add network adapters. If you're administering a multiprocessor system that doesn't distribute interrupts symmetrically, you can improve the distribution of the processor workload by adding network adapters so that there's one adapter for every processor. Generally, you add adapters only when you need to improve your system's throughput.
  • Limit connections. Consider reducing the maximum number of connections that each IIS 5.0 service accepts. Although limiting connections can result in connections that are blocked or rejected, it helps ensure that accepted connections are processed promptly.

Calculating Memory Cost

Some Web services, such as IIS 5.0, run in a pageable user-mode process. The process in IIS 5.0 is called Inetinfo (INETINFO.EXE). When a process is page-able, the system can remove part or all of it from RAM and write it to disk if there isn't enough free memory.

If part of the process is paged to disk, the service's performance suffers, as shown in Figure 7.5.

Figure 7.5  Paging a process to disk (Image unavailable)

It's very important to make sure that your server or servers have enough RAM to keep the entire process in memory at all times. The Web, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) services in IIS run in the Inetinfo process. Each of the current connections is also given about 10 KB of memory in the Inetinfo working set (assuming that the application is running in-process).

The working set of the Inetinfo process should be large enough to contain the IIS object cache, data buffers for IIS 5.0 logging, and the data structures that the Web service uses to track its active connections.

You can use System Monitor to monitor the working set of INETINFO.EXE. Because ISAPI DLLs run in the out-of-process pool by default, you'll need to monitor them separately from INETINFO.EXE. unless you've changed that setting, and you'll also need to be aware that out-of-process counter information is added together. This makes it difficult to single out any one process or application. (If your site uses custom ISAPI DLLs, those DLLs should incorporate their own counters so that you can monitor them individually.)

You should log this data for several days. You can use performance logs and alerts in System Monitor to identify times of unusually high and low server activity.

If the system has sufficient memory, it can maintain enough space in the Inetinfo working set so that IIS 5.0 rarely needs to perform disk operations. One indicator of memory sufficiency is how much the size of the Inetinfo process working set varies in response to general memory availability on the server. Make sure to examine data collected over time, because these counters display the last value observed rather than an average.

IIS 5.0 relies on the operating system to store and retrieve frequently used Web pages and other files from the File System Cache. The File System Cache is particularly useful for servers of static Web pages, because Web pages tend to be used in repeated, predictable patterns.

If cache performance is poor when the cache is small, use the data you've collected to deduce the reason that the system reduced the cache size. Note the available memory on the server and the processes and services running on the server, including the number of simultaneous connections supported.

When you add physical memory to your server, the system allocates more space to the file system cache. A larger cache is almost always more efficient, but typically it's a case of diminishing returns—each additional megabyte of memory adds less efficiency than the previous one. You must decide where the trade-off point is: the point at which adding more memory gets you so little improvement in performance that it ceases to be worthwhile.

Servers running IIS 5.0, like other high-performance file servers, benefit from ample physical memory. Generally, the more memory you add, the more the servers use and the better they perform. IIS 5.0 requires a minimum of 64 MB of memory, but at least 128 MB is recommended. If you're running memory-intensive applications, your server could require a much larger amount of memory to run optimally. For example, most of the servers that service the MSNBC Web site have at least 1 GB of memory.

Because memory usage doesn't directly relate to the number of concurrent users but rather to the content of the site (caching, out-of-process DLLs, etc.), a cost per user can't be calculated aside from the 10 KB per connection. In this instance you should monitor

  • The amount of Inetinfo that's paged out to disk
  • Memory usage during site operation
  • The efficiency of the cache utilization, or the cache-hit ratio
  • The number of times the cache is flushed
  • The number of page faults that occur

Calculating Disk Cost

Web services such as IIS 5.0 write their logs to disk, so there's usually some disk activity, even when clients are hitting the cache 100 percent of the time. Under ordinary circumstances, disk activity, other than that generated by logging, serves as an indicator of issues in other areas. For example, if your server needs more RAM, you'll see a lot of disk activity because there are many hard page faults. But there will also be a lot of disk activity if your server houses a database or your users request many different pages.

Since IIS caches most pages in memory, the disk system is rarely a bottleneck as long as the Web servers have sufficient installed memory. However, the Microsoft SQL Server computer does read and write to the disk on a frequent basis. SQL Server also caches data but uses the disk a lot more than IIS. For that reason, the capacity testing for Northwind Traders focuses on the SQL Server computer. However, you should calculate capacity on all servers where disk activity could become a bottleneck. You can use a tool such as System Monitor to record a site's disk activity while a WAST script is running for each operation.

This section is concerned with disk utilization and the effects of read and write operations. Determining whether you have adequate disk storage is a process separate from this one. Storage requirements are discussed in Lesson 3, "Planning Network Capacity."

For the SQL Server computer used by Northwind Traders, the percentage of disk utilization is based on a calibration of a maximum of 280 random seeks per second. For example, when the Pentium II server generates 2.168 Add Item operations, the SQL Server computer performs 9.530 disk seeks (for a disk utilization of 3.404 percent). You should calculate disk cost by dividing disk seeks per second by operations per second (which you'll have determined as part of the user profile). In this case the Add Item operation generates 4.395 disk seeks per shopper operation.

You can use the following equations to determine disk costs:

Disk reads per second ÷ Operations per second = Disk read cost per operation
Disk writes per second ÷ Operations per second = Disk write cost per operation

Table 7.7 illustrates the results from calculating disk reads on the Northwind Traders site.

Table 7.7  Disk Read Measurements for Northwind Traders

Operation Disk Reads per Second Operations per Second Percentage of Disk Disk Cost
Add Item 9.530 2.168 3.404% 4.396
Basket 7.050 8.728 2.518% 0.808
Checkout 19.688 0.903 7.031% 21.803
Clearitems 8.956 9.384 3.199% 0.954
Default 0.248 28.330 0.089% 0.009
Delitem 4.628 3.633 1.653% 1.274
Listing 0.148 5.533 0.053% 0.027
Lookup 0.063 12.781 0.023% 0.005
Lookup_new 9.275 12.196 3.313% 0.760
Main 0.120 8.839 0.043% 0.014
Browse 0.103 6.033 0.037% 0.017
Search 0.100 8.205 0.036% 0.012
Welcome 0.080 31.878 0.029% 0.003

Once you've calculated the disk cost per read operation, you must calculate the disk costs of write operations.

You can then use your calculations for your read and write operations to calculate your disk costs per user per second. As in your CPU cost calculations, you should multiply your cost per operation by operations per second. For example, if your disk cost for a Default read operation is 0.0009 and your usage for that operation is 0.003804 operations per second, your disk cost per user for that operation is 0.0000034 kilobytes per second (KBps).

Once you've calculated the cost per operation, you can add those costs together to arrive at the total disk load per user per second. You can then use that number to determine your disk system's capacity, which will be based on the load supported by your particular disk configuration.

Calculating Network Cost

Network bandwidth is another important resource that can become a bottleneck. You can calculate total network cost from the sum of the costs of the individual operations. However, two network costs are associated with each shopper operation: the connection between the Web client and the Web server and the connection between the SQL Server computer and the Web server. Sites that are more complex can have more types of connections, depending on the number of servers and the site's architecture.

On a switched Ethernet LAN, traffic is isolated so network costs aren't added together. On an unswitched Ethernet LAN, network traffic is cumulative so network costs are added together.

When a user performs an operation, the action generates network traffic between the Web server and the Web client, as well as between the Web server and the data server (if a database needs to be accessed).

For example, suppose the Add Item operation for Northwind Traders shows that optimal throughput is 0.000293 operations per second. The network cost of Add Item is 5.627 KBps per operation between the Web client and the Web server and 129.601 KBps between the Web server and the SQL Server computer, as shown in Figure 7.6. Most of the traffic generated by the Add Item operation is between the Web server and the SQL Server database.

Figure 7.6  Network costs of an Add Item operation (Image unavailable)

You can figure out the network cost per user per operation by using the following formula:

(Operations/sec. × Web network cost) + (Operations/sec. × Data network cost) = Cost per user per second

For example, you'd use the following calculation to determine the cost per user per second for the Add Item operation:

(0.000293 × 5.627) + (0.000293 × 129.601) = 0.039622

Table 7.8 shows the total bytes transmitted per operation (total network cost per user per second) on an unswitched Ethernet LAN. Web network cost represents the bytes transmitted per operation between the Web client and the Web server. Data network cost represents the bytes transmitted per operation between the SQL Server computer and the Web server.

Table 7.8  Network Costs for Northwind Traders

Operation Usage Profile Operations per Second Web Network Cost Data Network Cost Cost per User per Second (Web Server) Cost per User per Second (SQL Server) Total Cost per User per Second
Add Item 0.000293 5.627 129.601 0.001649 0.037973 0.039622
Add Item + Checkout 0.000183 24.489 55.215 0.004481 0.010104 0.014586
Default (home page) 0.003804 1.941 0 0.007384 0 0.007384
Listing 0.000421 25.664 23.134 0.010805 0.009739 0.020544
Login 0.000288 17.881 1.380 0.00515 0.000397 0.005547
Product 0.006102 21.548 21.051 0.131486 0.128453 0.259939
Register 0.000176 5.627 129.601 0.00099 0.02281 0.0238
Search (Bad) 0.000170 20.719 10.725 0.003522 0.001823 0.005345
Search (Good) 0.002391 20.719 10.725 0.049539 0.025643 0.075183
TOTAL           0.45195

The network cost per user is 0.45195 KBps. You can use this figure to calculate the total network traffic. For example, if 100 concurrent users are accessing your site, the total network traffic is 45.195 KBps. For 10,000 users, the total traffic is 4,519.5, and for 20,000 users, the total traffic is 9,039 KBps.

If the network is a Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Ethernet network running at 100 Mbps, or 12.5 megabytes per second (MBps), collisions will cause network congestion. For this reason, you shouldn't push network utilization above 36 percent, which means no more than 4.5 MBps on the network. The Northwind Traders network reached the 4.5 MBps threshold at about 10,000 users, which is the site's capacity. At 20,000 users, the network will become congest ed due to excessive collisions and a bottleneck will result.

Remember to measure network traffic for the entire site and not just for individual servers.

As your site grows, network capacity can become a bottleneck, especially on sites where the ASP content is relatively simple (low CPU load) and the content (like static HTML or pictures) is relatively large. A few servers can easily serve the content to thousands of users, but the network might not be equipped to handle it. In some cases most of the traffic on the network flows between the Web server and the SQL Server computer.

Lesson Summary

You should take five steps to determine your cost per user: analyzing the typical user, calculating CPU cost, calculating memory cost, calculating disk cost, and calculating network cost. You must analyze the typical user so that you can estimate how much demand a user places on the system. You can estimate this demand by determining the operations that users perform and how often they perform them. Once you've created a typical user profile, you can calculate CPU usage. You can calculate the cost per user per operation by first calculating the CPU cost of an operation. You can then determine the CPU usage per operation and then add those calculations together to arrive at a cost per user. In addition to CPUs, you should make sure that your server or servers have enough RAM to keep the entire process in memory at all times. If you're running memory-intensive applications, your server could require a much larger amount of memory to run optimally. Because memory usage doesn't relate directly to the number of concurrent users, but rather to the site's content, a cost per user can't be calculated aside from the 10 KB per connection. To determine disk usage, you must calculate read operations as well as write operations. You can then use your calculations for your read and write operations to calculate your disk costs per user per second. You should multiply your cost per operation by operations per second. Once you've calculated the cost per operation, you can add those costs together to arrive at the total disk load per user per second. Network bandwidth is another important resource that can become a bottleneck. You can calculate total network cost from the sum of the costs of the individual operations.

Activity 7.1: Calculating CPU Usage

You're the network administrator for Blue Yonder Airlines. A new search functionality has been added to your company's Web site, and you want to calculate the CPU usage for the Search operation. You're testing the operation on a server that's configured with three 400 MHz Pentium II processors.

Table 7.9 provides the parameters you should use when calculating Web usage.

Table 7.9  ;CPU Usage Information for Search Operation

Type of Information Details
CPU utilization (percentage of available CPU at optimum page throughput) 92.47%
Page throughput (pages per second) 18.21
Number of times a page is used per operation (requests per operations) 2
User profile operations per second (frequency) 0.00139
Upper bound of CPU 786 MHz
  1. Your first step is to determine the CPU cost per operation. In order to calculate this cost, you must first determine the CPU usage. How do you calculate the CPU usage for the Search operation?
  2. Now that you've calculated the CPU usage, you can use that calculation to determine the cost of the operation. How do you calculate the CPU cost for the Search operation?
  3. You can now use the cost per operation to figure out the cost per user. How do you calculate the CPU cost per operation per use?

Activity 7.2: Calculating Network Bandwidth

The Wingtip Toys company has hired you to administer its Web site, which is located on an unswitched Ethernet LAN. In the past users have often had trouble accessing the company's Web site. You want to determine the network cost per user. You plan to do this by first determining the cost per operation. You decide to start with the Add Item operation.

Table 7.10 provides the parameters you should use when calculating Web usage.

Table 7.10  Network Usage Information for Add Item Operation

Type of Information Details
Usage profile operations per second 0.003804
Web network cost 4.297
Data network cost 119.36
  1. Your first step is to determine the cost per user for the Web server. How do you calculate that cost?
  2. Next you must determine the cost per user for the data server. How do you calculate that cost?
  3. How do you calculate the total cost per user per second?

Lesson 3: Planning Network Capacity

When planning the capacity requirements for your Web site, you must determine the installation's current and future needs and then choose the hardware and software that meets those needs. The planning process includes many steps, such as determining the site's purpose, identifying the user base, and finding potential bottlenecks. This lesson describes each of the steps that make up the capacity planning process.

After this lesson, you will be able to
  • Identify and describe the steps necessary to plan your Web site's capacity
  • Plan the capacity requirements for your Web site

Estimated lesson time: 30 minutes

The Planning Process

Planning for your network's capacity requirements involves a number of steps. This section describes each of them.

Determining the Purpose and Type of Site

When you begin to plan the capacity requirements for your site, you must identify the site's purpose and what type of site you'll create. For example, you might be creating a transaction site that allows users to retrieve and store information, typically in a database. A transactional site involves both reliability and security requirements that don't apply to other types of sites.

In addition to determining the type of site, you must determine whether the site will support some form of dynamic content. Dynamic content takes many forms and can be provided by a wide variety of Internet and database technologies, such as SQL, ASP, ISAPI, or CGI.

At its simplest, dynamic content involves the Web server contacting a database, retrieving data, formatting it, and then sending it to a user's browser as a Web page. For example, if a user wants to see information on a specific product, the server might contact a SQL Server database to retrieve the product's description, a photo, price information, and whether or not the product is in stock. The resulting page would display in the user's browser using conventional HTML as if it were a static Web page, but it would be created on the fly by the server when the user requests it. A site that makes use of dynamic content requires much more processing capability than a static site.

Identifying the User Base

The next step in calculating your Web site's capacity is to determine how many people typically use the site concurrently. This data usually comes from two main sources: market analysis and systems analysis.

If a site has yet to be built or launched, the site's owners and operators probably will have commissioned a market analysis report that seeks to predict how much traffic the site can expect to receive at the time of the launch and afterward. Keep in mind that, as with any forecast, these numbers can be inaccurate.

If the site is already up and running, you should analyze your Web server log files to get a picture of how many hits the site receives at any given time as well as any usage trends that would indicate whether parts of the site have become more or less popular over time. When calculating how many users a site currently supports, remember to base your calculations on peak usage, rather than on typical or average usage.

Figure 7.7 shows an example of site usage. The chart illustrates average usage figures for a Web site that receives a great number of hits in the morning, fewer in the afternoon, and fewer still in the evenings. When planning capacity, this site's operators should use data from the mornings as a baseline.

Figure 7.7  Web site usage numbers (Image unavailable)

The site draws about 29,000 hits over six hours on Friday mornings, averaging 1.34 users per second. Taking the total number of weekly hits and averaging them over all seven days yields a much lower figure, 0.54 users per second. Using this lower figure as a baseline for capacity planning can lead to capacity shortfalls during busy periods.

You can determine the number of concurrent users by dividing the number of users by sessions totals. For example, if the site receives 500,000 users per day at an average session time of 11 minutes, you would use the following calculation to find the number of concurrent users:

500,000 ÷ (24 hours × 60 minutes ÷ 11 minutes per session) = 3,819 users

Of course, this doesn't mean you can expect to see 3,819 users at any random time. Sometimes the traffic will peak at a much higher figure; therefore, one of the most important principles of capacity planning is to use peak activity, rather than average activity, as a baseline. As a rule of thumb, account for usage spikes and peaks by multiplying the average number of concurrent users by 2 (although this multiplier may differ depending on the nature of the site). In this case, doing this yields a figure of 7,600 concurrent users. If your site experiences peak traffic that's more than twice the average traffic, consider this fact when determining where to set the baseline.

Determining Hardware Needs

You can determine your site's hardware requirements by taking the number of anticipated or measured visitors that a site will have during a period of time and comparing it with the hardware's capacity.

CPU Requirements

Web applications tend to be processor-bound. Contention issues, caused by more than one thread trying to execute the same critical section or access the same resource, can cause frequent expensive context switches and keep the CPU busy even though the throughput is low. It's also possible to have low CPU utilization with low throughput if most threads are blocked, such as when waiting for the database.

There are two basic ways to get the processing power you need: you can add additional processors to each server, or you can add servers.

Adding processors to an existing server is often less expensive (and less troublesome) than adding servers. But for most applications there comes a point when adding processors doesn't help. In addition, there is a limit to the number of processors that the operating system can support.

Adding servers allows you to scale linearly to as large a Web farm as you need. (Linear scaling means that two servers handle twice the load of one, three servers handle three times the load, nine servers handle nine times the load, and so on.)

Suppose you're using a dual-processor 400 Pentium II computer that is running Windows Server 2000, and you determine that the CPU capacity is 1,350 users. Your site should support 7,600 concurrent users. To determine how many servers you'll need to handle peak traffic, you must divide 7,600 by 1,350, as follows:

7,600 concurrent users ÷ 1,350 users per server = 6 servers

At times of normal usage, the load on the six servers will be lower, as shown here:

3,800 concurrent users ÷ 6 servers = 634 users per server

This means that the site is operating at 50 percent of site capacity when serving the anticipated amount of users. This is very important to sites that might experience usage spikes from time to time.

Memory Requirements

RAM access (at about 10 ns) is about a million times faster than disk access (about 10 ms), so every time you have to swap a page into memory, you're slowing down the application. Adding sufficient RAM is the best and least expensive way to get good performance from any system.

You can make sure your application has enough memory by checking the paging counters (paging should be rare once the application is running) and by checking the working set size, which should be significantly smaller than available RAM in Windows 2000.

Storage Requirements

Network storage solutions are rapidly becoming available as the number and size of enterprise networks increase. Every organization has different priorities for selecting media and methods for data storage. Some are constrained by costs, and others place performance before all other considerations.

As you assess your storage needs, you need to compare the possible loss of data, productivity, and business to the cost of a storage system that provides high performance and availability. Consider the following needs before you develop your storage management strategy:

  • Technologies that are the most cost-effective for your organization
  • Adequate storage capacity that can easily grow with your network
  • The need for rapid, 24-hour access to critical data
  • A secure environment for data storage

When looking for the most cost-effective solution, you need to balance the costs of purchasing and maintaining hardware and software with the consequences of a disastrous loss of data. Costs can include the following expenses:

  • Initial investment in hardware, such as tape and disk drives, power supplies, and controllers
  • Associated media such as magnetic tapes and compact discs
  • Software, such as storage management tools and a backup tool
  • Ongoing hardware and software maintenance costs
  • Staffing
  • Training in how to use new technologies
  • Off-site storage facilities

Compare these costs to the following expenses:

  • Replacement costs for file servers, mail servers, or print servers
  • Replacement costs for servers running applications such as SQL Server or Systems Management Server (SMS)
  • Replacement costs for gateway servers running Routing and Remote Access Service (RRAS), SNA Server, Proxy Server, or Novell NetWare
  • Workstation replacement costs for personnel in various departments
  • Replacement costs for individual computer components, such as a hard disk or a network card

Another important factor to consider when you select a storage system is speed of data recovery. If you lose the data on a server, how fast can you reinstate that data? How long can you afford to have a server (or an entire network) down before it begins to have a serious impact on your business?

Storage technology changes rapidly, so it's best to research the relative merits of each type before you make a purchasing decision. The storage system you use needs to have more than enough capacity to back up your most critical data. It should also provide error detection and correction during backup and restore operations.

Database Server and Disk Requirements

The database is a potential bottleneck that can be very difficult to fix. For read/write real-time data you have to have exactly one copy of the data, so increasing database capacity is much trickier. Sometimes the bottlenecks will be in the database server, sometimes they'll be in the disk array.

If database server capacity becomes an issue, you have a number of options. If CPU capacity is the issue, add additional CPUs. Database applications such as SQL Server make good use of additional processors. If the disk is the bottleneck, use a faster disk array. More RAM can help as well if the database application uses advanced caching techniques.

Another option is to split the database across multiple servers. The first step is to put the catalog database on a server or set of servers. Because the catalog is usually read-only, it's safe to replicate the data. You can also split off read-mostly data, such as customer information. But if you need multiple copies, replicating the information properly is more difficult.

However, it's possible that your site could get so busy that the read/write data has to be segmented. This is relatively simple for most applications; you can segment based on postal code, name, or customer ID. But for some database applications, it takes application programming in the database access layer to make this work. The layer has to know the server to go to for each record. However, applications such as SQL Server support splitting a table across multiple computers, with no application programming.

Determining Network Bandwidth

Once you determine how many users you want to serve during a given time, you have the lower limit for your network connection bandwidth. You need to accommodate both normal load and usage spikes.

Of course, the type of site you operate has a large effect on this issue. For example, if you're largely or entirely subscriber-based, or if your site is only on an intranet or an intranet/extranet combination, you probably already have a good idea of the maximum spike size. If, on the other hand, you issue software revisions to an audience of unknown size on the Web, there may not be a good way to predict the size of resulting spikes. You might, in fact, have to measure one or more actual occurrences to decide whether your bandwidth is sufficient.

A number of potential bottlenecks can occur in your networking hardware. First, your connection to the Internet might not be fast enough for all the bits you're sending. If your application becomes very popular, you might need to obtain a higher-speed connection or redundant connections. Redundant connections also increase your reliability and availability. You can reduce your bandwidth requirements to prevent bottlenecks by reducing the amount of data you send, especially graphics, sound, and video. Your firewall can also become a bottleneck if it's not fast enough to handle the traffic you're asking it to handle.

Note that you can't run an Ethernet network at anywhere near its theoretical capacity because you'll create many collisions (two senders trying to transmit at the same time). When a collision happens, both senders must wait a random amount of time before resending. Some collisions are inevitable, but they increase rapidly as your network becomes saturated, leaving you with almost no effective bandwidth.

You can reduce collisions a great deal by using switches rather than hubs to interconnect your network. A switch connects two ports directly rather than broadcasting the traffic to all ports so that multiple pairs of ports can communicate without collisions. Given that the prices of switches have significantly decreased in the last few years, it's usually a good idea to use a switch rather than a hub.

Defining the Site Topology

Each site has unique capacity requirements that can be affected by various considerations, such as available hardware and budget, available physical space for servers, and the amount of time the site is allowed to be offline. These requirements can have a direct effect on the design and construction of the site's physical infrastructure.

Figure 7.8 provides a sample of a site topology. Note that the diagram represents only one possible strategy for designing the network topology. Each organization has its own needs and consequently necessitates its own network design.

Figure 7.8  Sample site topology (Image unavailable)

When addressing site topology, consider the following questions:

  • What other server operations (such as backups and content replication) can influence site capacity? Because capacity measurements don't include these extraneous operations, you should measure the resources that these operations use and add them to the server in addition to the capacity required to handle Web traffic.
  • For example, some calculations are based on the fact that ASP pages are cached and objects are in memory. When content replication takes place, IIS flushes most of its cache or Windows swaps a lot of the cache to disk, which causes paging and degrades system performance. You should determine how much memory content replication takes and then add it to the amount of memory your calculations predict are necessary to achieve the desired capacity.

    A server rarely does only one thing at a time but rather performs a "symphony" of different operations at once. A carefully tuned server environment is like a well-conducted symphony. You can't let only one operation run and then measure it and expect that measurement to be accurate. Often servers and entire sites have scheduled operations, such as content replication or content precaching, that takes place at regular intervals.

  • How often do you expect usage spikes to occur? The general rule is to plan enough capacity for twice the average number of concurrent users. If you anticipate significant usage spikes that exceed this baseline, plan for surplus CPU, disk, memory, and network capacity. Remember to take growth into consideration, as well as possibly more complex content in the future.
  • How important is it to be operational 100 percent of the time? How often will servers be offline for maintenance? If 100 percent site availability is critical, plan for system redundancy. Duplicate critical resources and eliminate single points of failure.
  • One way to do this is to use cluster technologies. You can use NLB to cluster Web servers, and the Cluster service to cluster SQL Server computers. With these technologies in place, you can take some servers offline for upgrades or repairs while the remaining servers continue to run the site.

  • When will you undertake capacity planning again? What growth do you expect? How will content complexity change? Over time, the average number of concurrent users on a site rises or falls, the content and content complexity change, and the typical user profile changes. These changes can have a big impact on a site's capacity. Take change and growth into account when doing capacity planning and undertake it regularly or whenever these factors change sufficiently to affect site capacity.

Finding Potential Bottlenecks

Find out what's likely to break first. Unless your site is extremely small, you'll need a test lab to discover the bottlenecks. The following steps provide a guideline for determining potential bottlenecks:

  1. Draw a block diagram showing all paths into the site. Include, for example, links to FTP download sites as well as other Uniform Resource Locators (URLs).
  2. Determine what machine hosts each functional component (database, mail, FTP, and so on).
  3. Draw a network model of the site and the connections to its environment. Define the topography throughout. Identify slow links.
  4. For each page, create a user profile that answers the following questions:
    • How long does the user stay on the page?
    • What data gets passed to (or by) the page?
    • How much database activity (or other activity) does the page generate?
    • What objects live on each page? How system-friendly are they? (That is, how heavily do they load the system's resources? If they fail, do they do so without crashing other objects or applications?)
    • What is the threading model of each object? (The agile model, in which objects are specified as both-threaded, is typically preferable and is the only appropriate choice for application scope.)
  5. Define which objects are server-side and which are client-side.
  6. Build a lab. You'll need at least two computers, because if you run all the pieces of WCAT on one computer, your results will be skewed by the tool's own use of system resources. Monitor the performance counters at 1-second intervals. When ASP service fails, it does so abruptly, and an interval of 10 or 15 seconds is likely to be too long—you'll miss the crucial action. Relevant counters include CPU utilization, pool nonpaged bytes, connections/sec, and so on.
  7. Throw traffic at each object, or at a simple page that calls the object, until the object or the server fails. Look for the following:
    • Memory leaks (steady decrease in pool nonpaged bytes and pool paged bytes)
    • Stop errors and Dr. Watsons
    • Inetinfo failures and failures recorded in the Event Log
  8. Increase the loading until you observe a failure; document both the failure itself and the maximum number of connections per second you achieve before the system tips over and fails.
  9. Go back to the logical block diagram, and under each block fill in the amount of time and resources each object uses. This tells you which object is most likely to limit your site, presuming you know how heavily each one will actually be used by clients. Change the limiting object to make it more efficient if you can, unless it's seldom used and well off the main path.
  10. Use the Traceroute utility among all points on the network. Clearly, you can't trace the route throughout the entire Internet; but you can certainly examine a reasonable number of paths between your clients and your servers. If you're operating only on an intranet, trace the route from your desk to the server. This gives you a ballpark estimate of the routing latencies, which add to the resolution time of each page. Based on this information, you can set your ASP queue and database connection timeouts.

Upgrading Your Web Site

Once you've determined how many users per server your site can support, you can consider scaling the site to support more users or to better serve the users you already have.

You can use three basic strategies to upgrade your site:

  • Increase the number of users per server
  • Increase the total number of concurrent users the site can support
  • Decrease the latency of the site for faster response times

To implement these strategies, you can use one or more of the following options:

  • Optimizing content  Redesign your dynamic content to impose less of a burden on the site architecture. You can do this by writing smarter ASP or by changing the site so the average user (as defined by the user profile) calls heavy ASPs less often.
  • Improving server performance (scaling up)  Add more and faster CPUs and more memory; upgrade to faster software, such as upgrading from Windows NT 4 to Windows 2000; and tune the server by optimizing software configuration.
  • Adding servers (scaling out)  Add more servers to your Web clusters.

Measure the effect of these changes by analyzing your site before and afterward and then comparing the results. This can also help you predict the effects of future changes.


Scalability refers to how well a computer system's performance responds to changes in configuration variables, such as memory size or numbers of processors. This, however, is often difficult to gauge because of the interaction of multiple variables, such as system components of the underlying hardware, characteristics of the network, application design, and the operating system's architecture and capabilities. Organizations need to have the flexibility to scale server-based systems up or out without compromising the multipurpose and price performance advantages of the operating system platform.

Scaling up is achieved by adding more resources, such as memory, processors, and disk drives, to a system. Hardware scalability relies on one large extensible machine to perform work.

Scaling out is achieved by adding more servers. Scaling out delivers high performance when an application's throughput requirements exceed an individual system's capabilities. By distributing resources across multiple systems, you can reduce contention for these resources and improve availability. Clustering and system services, such as reliable transaction message queuing, allow applications to scale out in this manner. Software scalability depends on a cluster of multiple moderately performing machines working in tandem. NLB, in conjunction with the use of clustering, is part of the scaling out approach to upgrading. The greater the number of machines involved in the load balancing scenario, the higher the throughput of the overall server farm.

Scaling out allows you to add capacity by adding more Web servers to an existing cluster or by adding more clusters. Although more expensive than upgrading a server, adding a server often gives a bigger performance increase and confers operational flexibility.

Making a Decision

The process for planning your network's capacity requirements includes a number of steps. In each step you must make decisions about your site's operations. Table 7.11 describes many of the considerations you should take into account for each step.

Table 7.11   Capacity Planning

Step Description
Determining the purpose and type of site You must decide on the type of site, such as transactional, e-commerce, or information. You must also decide whether the site will have dynamic (as opposed to static) content, and if so, how that content will be delivered. For example, will you be using ASP or ISAPI?
Identifying the user base You must determine how many people will be using the site concurrently.
Determining hardware needs You must base your hardware requirements on the number of anticipated concurrent users at peak usage times. To get the processor power you need, you can add additional processors to each server or add more servers. You should also ensure that you have plenty of RAM to avoid having to swap pages into memory. Decisions about disk storage strategies must balance the cost of equipment against the consequences of a loss of data.
Determining network bandwidth You must base your bandwidth requirements on the number of anticipated concurrent users at peak usage times.
Defining the site topology When defining the site topology, you must decide what server operations can influence site capacity, how often you expect usage spikes, how important is it to be operational 100 percent of the time, and what kind of growth you expect.
Finding potential bottlenecks You should test your site to try to find any potential bottlenecks.
Upgrading your Web site When necessary, you should either scale out or scale up your site. You can also streamline content to improve performance.


When planning your Web site's capacity requirements, you should adhere to the following guidelines:

  • Identify your number of concurrent users by performing a market analysis (if the site hasn't been launched yet) or by analyzing your Web server logs (if the site is already running).
  • Use peak traffic figures to determine the maximum number of concurrent users.
  • Base hardware and network bandwidth needs on the peak number of concurrent users. Processor power and RAM must be sufficient to avoid performance degradation at times of peak usage. Storage should be adequate enough to ensure the performance and availability required for your Web site.
  • The site topology must take into consideration server operations such as backup and replication, performance during expected usage spikes, availability requirements, and expected future growth.
  • Test for potential bottlenecks before implementing your site.
  • Upgrade your site by scaling out or scaling up. Scaling out generally provides a larger increase in performance and greater operational flexibility.

Example: Capacity Planning for Coho Vineyard

Coho Vineyard is implementing a Web site to help market its organization. Before implementing the site, the company tested for potential bottlenecks to try to determine where problems might arise. Figure 7.9 shows the network topology for the Web site.

Figure 7.9  Coho Vineyard site topology (Image unavailable)

The Coho Vineyard site includes four identical Web servers that are configured as an NLB cluster. In addition to the network connecting the Web servers to the Internet, the Web servers are also connected through a private local area network (LAN) to the database tier and other specialized servers. These include the queued components server (for credit card authorizations and fulfillment), the box that runs the primary domain controller (PDC), and the Domain Name System (DNS) service. For data services, the site uses a failover cluster of two servers connected to a common RAID disk array. An administrative and monitoring network is connected to all of the computers. This means that the Web servers are connected to three networks; each of these servers is configured with three network adapters.

Each of the Web servers is configured with two 400 MHz processors. When the Coho Vineyard administrators load-tested the site, they discovered processing degradation at peak loads. When a third processor was added to each computer, performance increased by about 30 percent, which was enough to handle anticipated peak usage.

Each Web server is configured with 256 MB of memory. Throughout the testing and analysis process, memory never appeared to be an issue. Paging was rare, so no configuration changes were made to memory.

During the test phase, the administrators discovered that the database wasn't working very hard and that the Web servers were sometimes very busy and then sometimes very slow. The problem resulted from using a 100 Mbps hub to connect the Web servers with the database servers. Because all the traffic was going through the hub, it had become swamped, thereby blocking the system from processing transactions quickly. When the administrators replaced the hub with a switch, the bottleneck was removed.

Database server capacity hasn't been an issue for Coho Vineyard's site. Only about 25 percent of the data servers' capacity is being used, even when all four Web servers are running at 100 percent CPU utilization. Disk and memory capacity have also proven to be more than adequate.

Lesson Summary

Planning your network's capacity requirements involves several steps. The first step is to determine the site's purpose and type. You must know what the site will be used for and what kind of content it will support. You must also identify how many people will be using the site concurrently. Your estimate should take into account peak usage as well as average per user usage. Once you've determined your estimated number of concurrent users, you can then plan your hardware and network bandwidth needs. Both these needs should take into account the site's peak usage number of concurrent users. Your system should have enough processing power and memory to meet the demands of peak usage. When assessing your storage requirements, you must weigh the expense of a system that provides high performance and availability against possible loss of data, productivity, and business. Overall, your site topology should take into consideration server operations, expected peak usage, availability requirements, and growth. You should also look for potential bottlenecks in your site to find out what's likely to break first. When you upgrade your site, you can improve performance and availability by optimizing content, improving server performance, or adding servers.

Lab 7.1: Planning CPU and Bandwidth Capacity

After completing this lab, you'll be able to

  • Calculate the CPU usage and bandwidth usage per user
  • Determine the number of Web servers and CPUs necessary to support your users
  • Determine the capacity of your network bandwidth

About This Lab

In this lab you'll determine the capacity requirements for your network. You'll be focused specifically on CPU capacity (and the number of Web servers) and the capacity supported by your network bandwidth.

Before You Begin

Before you begin this lab, you must be able to

  • Administer Windows 2000 Advanced Server
  • Understand basic network and computer concepts related to user capacity

Scenario: Capacity Planning for Adventure Works

Adventure Works is a nationwide tour company that provides vacation packages to clients traveling around the world. The company is upgrading its Web services so that clients will be able to log on to the site so that they can receive information about packages customized to their specific needs. Until now users were simply able to access the site to view information about the various packages. To deliver the new services, administrators will be implementing a SQL Server back end. ASP will be used to access and display data from the database. The Adventure Works network is a 100-Mbps Ethernet network. Figure 7.10 provides an overview of the company's network topology.

Normally, the site services about 1,000 to 3,000 concurrent users, although at peak times that number can increase to up to 6,000 users. The company doesn't anticipate that the number of users will increase too greatly when the new services are implemented. The Web servers are each configured with three 400 MHz processors. The upper bound per computer is 755 MHz. As the administrator, you must determine the number of processors necessary to support the current usage and you must assess how much capacity the network supports.

Figure 7.10  The network topology of Adventure Works (Image unavailable)

Exercise 1: Identifying the User Base

In this exercise you must identify the number of concurrent users on which to base your capacity calculations. From there you must calculate the CPU and network costs per operation.

  1. How many concurrent users should your network support?
  2. Once you've determined the number of users, you can then calculate the CPU usage per users. The first step in performing these calculations is to identify the applicable operations and the data about each of those operations. Based on your analysis, you've identified the operations and necessary information about each operation (shown in Table 7.12).

    Table 7.12   Operations in the Adventure Works Network

    Operation CPU Utilization Requests per Second Request per Operation Operations per Second
    Default 96.15% 96.98 1 0.00128
    Add Item 92.08% 26.21 3 0.00102
    Listing 93.42% 29.29 2 0.00329
    Lookup 98.99% 82.08 2 0.00121
  3. What's the first step you must take to calculate the CPU usage per user?
  4. What's the next step that you should take to calculate the CPU usage per user?
  5. What's the CPU cost for each operation?
  6. Once you've determined the cost per operation, you can determine the cost per user per operation, and from there, determine the cost per user. What's the cost per user for each operation?
  7. What's the total cost per user for CPU usage?
  8. Now that you've determined the CPU usage per user, you can determine the network usage per user. Based on your analysis, you've identified the necessary information about each operation (shown in Table 7.13).

    Table 7.13  Network Costs of Operations

    Operation Operations per Second Web Network Costs Data Network Costs
    Default 0.003682 1.845 0
    Add Item 0.000254 4.978 127.756
    Listing 0.000523 26.765 24.123
    Lookup 0.001134 25.678 25.564
  9. Your first step is to calculate the network costs per operation. What's the network cost for the Default operation?
  10. What are the network costs of the remaining three operations?
  11. What are the total network costs per user?

Exercise 2: Determining CPU Requirements

In this exercise you'll determine how many Web servers you need in order to support the current number of users. You'll base your calculations on the costs per user that you determined in Exercise 1. At this point you should have all the base information that you need to calculate your CPU requirements.

  1. How much processing power does each server have and how much of that can be used?
  2. What is the total cost per user for CPU usage?
  3. How many concurrent users can the CPUs in each Web server support?
  4. Once you've determined how many concurrent users each machine will support, you should round down that amount to a whole number and use that figure to calculate the number of servers that you need. How many Web servers should your cluster contain?

Exercise 3: Determining Bandwidth Capacity

In this exercise you'll calculate whether your current network can support the number of concurrent users. You'll base your calculations on the costs per user that you determined in Exercise 1. At this point you should have all the information you need to make these calculations.

  1. What's the network bandwidth and how much of that bandwidth should you utilize when planning your capacity requirements?
  2. How many concurrent users will your network support?


Answering the following questions will reinforce key information presented in this chapter. If you are unable to answer a question, review the appropriate lesson and then try the question again. Answers to the questions can be found in the appendix.

  1. You're a network administrator at Contoso Pharmaceuticals. Your network is connected to the Internet by a T1 line. You want to know the maximum transmission rate for a 5-KB page. With overhead, a page transmission runs about 55,360 bits. What's the maximum transmission rate over the T1 line?
  2. You're implementing new tools on your company's Web site. You want to find out how long it will take users to download a 90 KB page (including overhead) over a 28.8 Kbps modem and a 56 Kbps modem. How many seconds will it take each type of user to download the page?
  3. Your company is implementing new services on their Web site. The new services include data access to a back-end SQL Server database. In testing and analysis, you discovered that the Add Item operation responds more slowly than you expected. You determine that the disk cost for the operation is 4.395 and the usage for that operation is 0.012345 operations per second. What's the disk cost per user per second for the Add Item operation?
  4. You're planning your network's capacity requirements. The site will be a transaction site that will allow users to store and retrieve information. Content will be dynamic: ASP hitting a SQL Server database. You anticipate 5,000 concurrent users at peak usage. What other steps should you take?
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)