email article printer friendly more resources

Stress-Test Your Web Site With WCAT
Microsoft's Web Capacity Analysis Tool can help you answer the question, How many users can this thing handle?
by Keyur Shah

October 15, 2004

For This Solution: Microsoft Windows 2003 Server Resource Kit

You're on a small team racing to put a Web server-based application in production in time to meet an immovable deadline when a coworker asks you "How many users can this thing handle?" You can make an educated guess and hope the application is sufficiently efficient and the hardware is up to the task. Or, you can run tests to see how much it can really handle.

If the hardware in question is running Windows NT, 2000, or 2003 Server, you're in luck. Bundled with Windows 2003 Server and included in the Windows 2000 Server Resource Kit is a handy tool called Web Capacity Analysis Tool (WCAT) that allows you to stress-test your system before unleashing users on it. In particular, WCAT helps you understand the load your system can handle before it reaches the point that users find unacceptably slow.

Web testing consists primarily of two tasks. The first is to apply stress to the Web site and to measure the maximum requests per second that the Web server can handle. This is known as quantitative measurement.

The second task is to determine the resources that prevent the requests per second from going higher. These resources or factors can be hardware, such as CPU or memory constraints, or other variables, such as Web server configuration settings. This second task involves more exercise and interpretation than the first.

To determine how much load a server can handle, you need to increase the stress on the Web server until the requests per second start to fall off. Usually, requests per second continue at a steady rate and then fall off rapidly and without warning. Placed in a graph, the data will look like a hockey stick where the inflection point is where responsiveness takes a dive. Dial back the level of stress and you'll see a rise in requests per second. The point just before the bend in the hockey stick is the maximum load the system can achieve in its present configuration.

To improve performance, a knee-jerk reaction is to draft an RFP for a server with a more muscular CPU. However, by digging deeper into your data you will probably find the CPU is not the bottleneck. Many other resources play an important role in throttling performance, such as RAM, network bandwidth, memory leaks in the application, poor database design, and so on.

One way to load test is do so manually using approximately 20 volunteers at PCs in a lab network who pound on your application while you observe the effects.

A better way is to use WCAT, or an automated tool like it such as Microsoft's Web Application Stress Tool, and third-party tools such as LoadRunner or Empirix. WCAT generates hard performance numbers that help the team visualize exactly where performance bottlenecks reside and how overall performance is affected by the use of complex HTML, adding images, using a RAID, or changing other variables. Most test workbenches consist of four elements:

1. Software that allows one machine to simulate many clients. You need to vary the test load by altering the number of clients submitting requests. The goal is to find the threshold where the server hardware and software become unusable.
2. A test script or set of scripts that put the software through its paces. A script is a test scenario and the steps a client takes to navigate Web pages and appropriate input for HTML fields. You create different scripts to depict different uses.
3. A log file to record data. Typical items stored are counters and results.
4. A separate, high-speed LAN to avoid any bottlenecks introduced by the network hardware or other traffic competing for bandwidth. As you may recall from high school chemistry, you need to control variables when conducting a science experiment or risk gathering irreproducible, useless data.

Used properly, you can expect WCAT to help you learn the optimum network configuration, which would further guide you in capacity planning for the Web servers. It can also help assure efficient code practices and proper database configuration.

Getting back to our opening scenario, it's safe to assume that during the initial launch, traffic will be moderate (the chance of a Slashdotting are low) and the Web applications and server would not suffer performance issues. However, we expect traffic to grow and double in the first 12 months. As traffic grows, we must anticipate its effect on performance.