The Web Capacity Analysis Tool

At Microsoft TechEd, I saw a demonstration of a Web application that could handle 7500 simultaneous users. When the company first built the application, the app would scale only to eight simultaneous users. The company improved this application's performance through testing. During the entire development cycle, the developers tested and tweaked the product. The only reason the application doesn't handle even more users is because the developers ran out of time to test and tweak it.

If you want to perform this type of testing of your systems, you can use the Web Capacity Analysis Tool (WCAT) from the Microsoft Windows Internet Information Server Resource Kit. WCAT measures the capacity potential of an IIS installation or application under a variety of client workload simulations. WCAT simulates loads against a Web server and logs the results. Using WCAT, you can test a server and obtain a good idea of how that server will perform when running Active Server Pages (ASP) or HTML applications.

This month, I cover what WCAT does and how to install it. Next month, I'll delve into the details of running and customizing tests.

Obtaining the Utility
You can obtain WCAT from the resource kit. However, be sure to check the Microsoft Web site (http://www.microsoft.com) for the most recent version. The version I found on the Web in September was version 4.13, which is newer than the version in the resource kit. (The Web site will always have a newer version than the resource kit.)

WCAT consists of several components, which Figure 1 shows:

You can install the components on one system or separate systems. In a test environment, installing the various components on separate systems places a typical load on your server and the network. Each WCAT Client can generate a load of 200 users on the Web server, assuming the client has enough memory to preclude paging operations. WCAT requires Windows NT 3.51 or later on all systems.

Installing WCAT
As I mentioned earlier, before you install WCAT, you need to check the Microsoft site to obtain the latest version. If you find a newer version, replace the existing WCAT setup files installed from the resource kit with these newer files.

To install the WCAT files, execute setup.exe for each of the three types of installations (i.e., server, controller, and client). Here's how to install the WCAT Server: A Setup Wizard appears to walk you through the installation. Screen 1 shows the first page of the wizard.

When Setup terminates, the WCAT Server files are in the inetpubwwwroot directory. Under this directory, you'll find a series of subdirectories starting with the Perfsize directory and ending with the Perfsize.99 directory.

Next, use the Setup Wizard to install the WCAT Controller on the system you want to use as the controller. The default directory for the controller is C:webctrl; the controller's executable file (wcctl.exe) and its support files are in that directory.

The last step is to install the WCAT Client software. Start setup.exe on each client system, and select the check box (Install WCAT CLIENT on this machine), then click Next. On the next page, either confirm the name and location of the installation folder or change it, then click Next. After setup finishes copying files, click OK, then click Finish.

The C:webclient directory is the default installation directory for the WCAT Client software and contains the client executable (wcclient.exe) and other support files. You can install the WCAT Client application on multiple systems to simulate various loads on the server; each client can simulate 200 connections. Because many browsers such as Microsoft Internet Explorer (IE) can open several connections at once, a connection doesn't necessarily equal a user. Monitor your testing carefully to determine the actual load you're placing on the server. You can control various elements during each test, such as

Configuring WCAT
The WCAT Controller is the key to testing your applications. The controller usually runs on a separate system and is responsible for controlling the operations. The controller's workload isn't counted in the test.

The controller supports several input files that control the test's operation. The input file names use the test name as the prefix, making them easy to identify. Table 1 describes the various controller files that WCAT uses.

You can use the standard controller files that come with the installation, or you can create your own controller files. You might use custom controller files to create a test configuration so you can test your applications and tweak the testing. The easiest way to generate a custom set of files is to modify the standard files, which are in the C:webctrlscripts directory.

When you run a test, WCAT generates one or two files. The system names these files with the test name and either a .log suffix (for the log file) or a .prf suffix (for the performance results file). The log file includes the test results in an analysis format. You can easily import the log file (it's in .csv format) into Microsoft Excel or another application for analysis.

If you execute the controller with the -p switch, WCAT also generates a .prf file. This file contains the Performance Monitor data that you request from the server when you specify the -p switch. You can review the .prf file to see what Performance Monitor tracked during test execution. The WCAT Controller creates the .prf file by executing Performance Monitor on the server and tracking either the default counters or the counters you specify with a performance counter file (.pfc) for the test. Thus, you can customize the data that you want Performance Monitor to track.

The standard .pfc file is server.pfc and is in the C:webctrlscripts directory on the controller system. The contents of the file are the following:

##   Counters for NT Server##   For IIS the process name #   is: inetinfo.exe##System% Total Processor TimeProcessor(0)DPC RateProcessor(0)Interrupts/secProcessor(0)DPCs Queued/secProcess(inetinfo)% Processor TimeProcess(inetinfo)% Privileged TimeProcess(inetinfo)% User TimeSystemContext Switches/secSystemSystem Calls/secProcess(inetinfo)Thread Count

You can see from this file that by default, WCAT can track things such as processor time, interrupts, and InetInfo objects. You can edit this file or create a new one to add your own counters.

WCAT and Systems
You can load WCAT on any number of systems. Microsoft designed WCAT to test real-life applications and servers. To run these kinds of tests, you must provide WCAT with the correct system configuration for all the systems involved. For example, you can't test an intranet application to see how well it runs on the network with just two or three systems. You must test it with a real-life scenario with interconnected systems on the network—just like your final intranet or Internet application will be.

Conversely, you can begin testing an application with two or three systems to see how it performs and tweak it to try to improve its performance. For example, suppose your developers are building an application, and you want to make sure they make it a high-performance application. You can set up three or four systems to run application tests before and after each change. Figure 1 shows a sample configuration with four systems. One system is the Web server that runs IIS and contains the WCAT Server files. One system on the network runs the WCAT Controller software; the other two systems run the WCAT Client software.

This configuration lets you run various tests with up to 400 connections, which is a pretty good load to place on an application. Using the scenario in Figure 1, you can design the WCAT test to use the application that the developers are building. Then, at various stages in the application's development, you can load the application on the server and test for performance gains. Your developers can change one thing at a time, rerun the test, and check its performance. This approach lets them tweak an application until it really flies, and you can see the test results and how the application performs. To test more connections, just add more clients.

A Testing Tip
When your developers test an application with WCAT, tweak it, and retest it, they'll get some type of results. Make sure you document those results and their test conditions. Also, make sure you post the key facts that the developers changed. For example, if you find out that disconnected record sets execute faster than connected record sets, post this information on your network or intranet along with a code sample that demonstrates how you conducted the test. Then, all your testers can learn from the experience of a few.

You can buy more powerful and flexible Web testing tools on the market than WCAT, but WCAT is low cost or free, if you obtain it from Microsoft's Web site. You can't beat that price.