- Shopping Bag ( 0 items )
Lesson 1: Introduction to Highly Available Web Solutions
Lesson 2: Determining System Availability
Lesson 3: Ensuring System Availability
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:
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....
|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|
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
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.
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)|
|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:
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 inprocess 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 serverside 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|
|Static file (FILE8K.TXT)||1,109||1,748||2,242||48||80||108|
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:
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."
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.
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:
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.
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.
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:
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|
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:
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)|
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)|
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:
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
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.
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|
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.
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 + 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|
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.
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.
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|
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|
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.
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.
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.
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.
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:
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:
Compare these costs to the following expenses:
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:
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.
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.
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:
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:
To implement these strategies, you can use one or more of the following options:
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
|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:
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.
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
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
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.
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|
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|
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.
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.
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.