It’s very important to know what your Internet or intranet server’s real capabilities are. You can use Performance Monitor for Web server benchmarking, but it has its limitations. Performance Monitor simply measures the server’s response to various conditions that already exist. And because Performance Monitor is purely passive, you can’t tell in advance how your server’s going to respond to actual client requests.

What you need is a way to actually judge how your server is going to respond to the work it will need to do. To help you test your servers, Microsoft created Web Capacity Analysis Tool (WCAT). WCAT can actually place a workload on your IIS server. You can then use WCAT to perform many different types of tests, including determining HTTP, SSL, and ASP capabilities. In this Daily Drill Down, I’ll introduce you to WCAT and show you how to use it.

When to use WCAT
WCAT is especially useful when you’re planning to upgrade your Web server’s hardware. You can use WCAT to test and compare software tweaks to your server. Prior to making changes to the server, you can run a WCAT test to place a specific workload on the server. After upgrading the hardware or tweaking the software, you can place the exact same workload on the server. Then you can see exactly what affect the upgrade will have on system performance.

WCAT can also be useful to create baselines to use when evaluating new servers. If you’re thinking about replacing one IIS server with another, you can use WCAT to test both servers and compare the results. If you don’t get significantly better results with the new server, you can potentially save yourself the cost of the upgrade.

The components
The WCAT tool is a part of the Windows 2000 Server Resource Kit. It’s composed of three main components: the WCAT Server, the WCAT Controller, and the WCAT Client. In the sections that follow, I’ll introduce you to each of these components and share with you the system requirements for each. I will also tell you how to install the components.

The WCAT Server
The WCAT Server is your IIS server. Although WCAT comes with the Windows 2000 Server Resource Kit, it can be used to test IIS 4.0 running under Windows NT and IIS 5.0 on Windows 2000 servers. The server component of the WCAT software is nothing more than several sets of sample content files (e.g., HTML, ASP, etc.). The server hosts these sample content files in the same way it would host any other Web site. As clients access the WCAT Server, the server responds to client requests, manages client connections, receives content requests, processes client requests, and sends responses. WCAT performs each test using different content sets.

If you’re wondering why WCAT uses sample files for the tests rather than your actual Web site, it’s because the sample files are of known file sizes. This way, it’s possible to tell how many seconds it took to process 1,000 requests for a 2-KB file for example. Plus, because the sample files are of a known quantity, you’ll be comparing apples to apples when using WCAT to run tests on disparate Web sites.

Compared to the other WCAT components, there are very few specific requirements for your server. You can use any IIS 4.0 or 5.0 server with 220 MB of free hard disk space and a functional TCP/IP connection that the client and the controller can use to access the server. Although there are no stringent server requirements, Microsoft recommends that the server have enough RAM to contain all static test pages in memory simultaneously—unless you happen to be testing the effects of low memory. Otherwise, the server may begin to depend on virtual memory, which would skew the test results as a result of its slow performance.

Installing the WCAT Server component is relatively easy. Simply insert your Windows 2000 Resource Kit CD and then run the SETUPEX.EXE file found in the \APPS\WCAT folder. You’ll then see a message stating that you’re about to install WCAT and asking if you want to continue. Click Yes to launch the Setup wizard. The wizard is a typical wizard; it asks you for the location of the folder to install to and whether you want to do a typical, minimal, or custom installation. For this article, I will explain how to perform a typical installation.

When the installation completes, there will be a folder called WCAT on your server. Create a share for this directory and make sure the client and the controller can both access the share point. Once you’ve shared the WCAT folder, open it and you’ll see Client, Controller, and Server sub folders. Open the Server sub folder and run the SERVER.EXE file. This will extract all of the server files to the server’s INETPUB\WWWROOT folder (unless you choose another location). The SERVER.EXE file will place over 1,500 files on your server in a matter of seconds.

The WCAT Controller
There tends to be a lot of overhead associated with a WCAT test. Because of this, a separate machine known as the WCAT Controller is used. By offloading many of the WCAT operations onto a separate machine, you can more accurately measure the server’s performance without bogging down the server with software used for running the tests.

The WCAT Controller uses three main input files for each test. First, there’s the configuration file. This file specifies things like the duration of the test and the number of clients. There’s also a script file, which specifies what Web pages the clients will be accessing during the test. Finally, there’s a distribution file, which tells the clients how often to request the Web pages specified in the script file. Although it’s beyond the scope of this article, the controller can also maintain a performance counter file. The performance counter file is a list of which Performance Monitor counters should be monitored on the server.

During the test, the WCAT Controller creates a log file in CSV format that contains all of the statistical data gathered during the test. If you were to use the performance counter file option, the controller would also create a performance results log file, which would be in PRF format.

Of the three WCAT components, the controller has the most stringent requirements. The WCAT Controller software consumes 10 MB of hard disk space and requires 16 MB of free RAM. In addition to requiring a valid TCP/IP connection to the server and client, the WCAT Controller requires that you use the Windows NT, Windows 2000, or Windows XP operating system.

To configure the WCAT controller, go to the machine that’s acting as a controller and map a network drive to the WCAT share point that you created. Open a Command Prompt window and navigate to the drive letter that you mapped to the WCAT share. Once you’ve switched to the appropriate network drive, enter the following commands:
CD\CONTROL
CONFIG ip address of the server (For example, CONFIG 147.100.100.50)

The WCAT Client
The WCAT Client is nothing more than a workstation running the WCAT client software. The WCAT Client software is a component that runs a single multithreaded process to connect to the WCAT Server via IIS. During the tests, the WCAT Client allows you to control things such as the number of client browsers accessing the server, the size and types of pages being accessed, the client request rate, the frequency at which different pages are requested, and the total duration of the test.

The WCAT Client software doesn’t run on Windows 9x or on Windows Me workstations. The WCAT Client runs only on Windows NT, Windows 2000, or Windows XP. The client machine requires at least 8 MB of free RAM, although SSL tests may require more. The client software consumes less than 1 MB of hard disk space. As with the server, the client must also have a functional TCP/IP connection to the server and to the controller. Microsoft also recommends that the processor in the client be at least as fast as the processor in the server.

Before you can install the client, you must first install the controller. Once the controller has been installed, go to the client machine and map a network drive to the WCAT share point that you created. Open a Command Prompt window and navigate to the drive letter that you mapped to the WCAT share. When you’ve switched to the appropriate network drive, enter the following commands:
CD\CLIENT
CONFIG [controller name] [ip address of the controller] (For example, CONFIG cartman 147.100.100.34)

You may have noticed that you can use the WCAT Client to control the number of simulated Web browsers. The WCAT Client is a single, multithreaded process, and each of the threads represents a virtual client. So if you use the maximum of 200 threads, you’ve simulated 200 Web browsers. Additionally, you can open multiple copies of Internet Explorer (IE). If you open two copies of IE, each running 200 WCAT sessions, you’ve simulated 400 connections to the server.

A word of caution about using too many virtual sessions

Beware your memory consumption on the client. If you use more memory than the amount of physical RAM present in the machine, the workstation will rely on virtual memory. Using virtual memory slows down the process and gives inaccurate results. If you need to run more virtual sessions than your client can handle, you can solve the problem by using multiple client computers.

Running a test
There are 10 different phases of the testing process:

  1. Preparing the controller input files
  2. Starting the clients
  3. Starting the controller
  4. Starting the server
  5. The warm-up period
  6. The test period
  7. The cool-down period
  8. The reporting period
  9. Preparing the output files
  10. Reading the output files

Preparing the controller input files
The first step in the testing process is to select the controller input files. There are lots of different controller input files available, plus you can use a text editor to customize your own test. For the purpose of this article, I’ll be using the 1K test, which repeatedly accesses a 1-KB file from the server. For a full description of all of the available tests, check out the WCATGUIDE.DOC file included with the WCAT software.

After you’ve decided which test to run, copy the test files from the \CONTROL\SCRIPTS folder on the shared network drive to the \CONTROL directory. For example, since I’m running the 1K test, I copied the 1K.CFG, 1K.DST, and 1K.SCR files to the CONTROL directory.

Starting the clients
The next step is to start the client machine. Open a Command Prompt and navigate to the CLIENT directory on the network drive that you mapped. Then type CLIENT to start the client software.

After you start the client software, you’ll see the error message shown in Figure A. This isn’t really an error, but rather a notice that the client will keep trying to attach to the controller every 10 seconds until a connection is established.

Figure A
The client attempts to connect to a controller that isn’t yet online.

Starting the controller
To start the controller, go to the controller PC and open a Command Prompt. Navigate to the CONTROL directory on the network drive that you mapped earlier. Enter the following command:
WCCTL –A [server IP address] –N [server name] –e [test name]

For example, on my test system, the command looked like this:
WCCTL –A 147.100.100.50 –N BART –E 1K

Starting the server
You must next start all the necessary services on the Web server. Usually, this means starting the HTTP service.

The warm-up period
As the test begins to run, you’ll see a Warming Up message appear on the controller. This message refers to the initial phases of the test. As the first few queries are made, the server hasn’t yet cached the data being requested. So if this part of the testing process were to be recorded, the results wouldn’t be representative of the server’s true performance.

The test period
Next, you’ll see the Running Test message appear. The testing process can take quite a while to complete. I ran a simple test on some fast machines, and the process took about 15 or 20 minutes.

The cool-down period
When the testing process completes, you’ll see a Cooling Down message. The cooling-down period involves stopping client requests. Like the warm-up period, the cool-down period isn’t recorded.

The reporting period
At this point, the clients report their results to the controller. If you have only one client, this is a very quick process. But if the controller must wait on information from many clients, you could be waiting awhile.

Preparing the output files
The preparation of the output file is where the information the clients sent to the controller is compiled into a single log file. Again, this process is quick if you are working with a single client but can take some time if there are many client reports to compile. You can see an overview of the entire testing process shown in Figure B.

Figure B

Reading the output files
Finally, it’s time to read the report the testing process generated. The test will create a log file in the CONTROL directory with the test name followed by the LOG extension. In my example, I ran the 1K test, so the filename is 1K.LOG. You can see an example of the log file shown in Figure C.

Figure C
This is the log file created by WCAT.

As you can see in the figure, the log file has three main sections. The first section is a header that contains some basic information about the test. The middle section contains the actual test results. In a real-life test, there would be an additional column for each additional client PC. Notice that the last column uses the client’s IP address as a header. This column contains the raw data collected by the client. The bottom section, which isn’t completely shown in the figure, shows a collection of statistics complied by the test.

Put your servers to the test
After you’ve run the tests, you have a baseline with which you can judge your servers. Using a combination of tweaking and testing, you’ll eventually get your IIS servers running at peak performance without much guesswork. All it takes is a little time and testing using WCAT.