Load Testing Exchange 2000

Now you need to add the servers and counters you want to monitor. (See Web Table 2 for suggested performance objects, counters, and instances for specific Exchange performance-monitoring categories.) The process is a bit different in Windows XP than it is in Win2K. In XP, click Add Objects, then enter the name of the server that you want to monitor. Wait for Performance Monitor to verify the connection and access privileges. If you don't have NetBIOS name resolution or administrator permissions on a particular server, the connection process might fail. After you establish a connection to the server, select a performance object, then click Add to add all counters and instances of that object. In Win2K, click Add to open the Select Counters dialog box, which Figure 6 shows. Select the server you want to monitor from the Select counters from computer drop-down list, then wait for Performance Monitor's verification. Next, select the All counters and All instances options. Click Add, then click Close, then click OK on the main settings dialog box to save the settings.

Alternatively, you can select a limited set of counters to capture data at a smaller interval and keep the log files fairly small (i.e., a few megabytes). With modern disk sizes, though, I select the All counters and All Instances options for the Performance Objects that Web Table 2 lists, then clean up later. Another common option in performance monitoring is to define two capture log files, one at 1-minute intervals over the 8-hour duration and one at 15-second intervals for an hour or two in the middle of the load test.

You're now ready to set the logging options. Double-click the log-settings file you just created to reopen the settings dialog box. On the Log Files tab, which Figure 7 shows, specify your log-file information. (Note that in Figure 7, I'm logging to the default location, which is my C drive. Therefore, I need to monitor disk space carefully.) The default log-file names are based on your log-settings name, which is why I suggest you use the server name so that you can easily separate and identify logs from each server. You can later move the full set of log files to a folder for each test run.

The Schedule tab, which Figure 8 shows, lets you choose more options than the original Windows NT 4.0 Performance Monitor did. You can schedule the start time for performance logging, and you can specify the end time as either an explicit time or as a number of hours after capture has started (I prefer the latter method). You can enter a command for LoadSim to run when a log file closes; I set up a netsend.cmd file to send me an alert. Click OK to close the dialog box.

Because you're capturing performance information remotely from computers across the network, you need to change the security parameters for Win2K's Performance Logs and Alerts service. By default, the service logs on as the Local System Account. You need to change the service's settings (which you can access through the MMC Services snap-in) to log on as a Domain Administrator account (not the local Administrator account).

You also need to enable logical disk counters to capture the performance data. To enable the counters for logical drives, open a command prompt and type

diskperf ­yv

To enable counters for both logical and physical drives, type

diskperf ­y

You can repeat this configuration process for each server you want to monitor, but a far easier method is available. Open the log-settings file, which Performance Monitor saves as an .htm file, in Notepad or another text editor. Save the file under a new name (by default, Notepad uses the .txt extension unless you put quotes around the new filename—e.g., "server1.htm"), then search for and replace the original server name with the new server name. Save your changes, then repeat the process for each server.

Performing Load Tests
Now you're ready to run the load test. You have two ways to go about this process: You can visit each load-generating client and select Run, Run Simulation from the LoadSim menu, or you can use fully automated testing (see the Web-exclusive sidebar "Fully Automated Testing with LoadSim 2000" at http://www.winnetmag.com, InstantDoc ID 24127, for details). Synchronizing the time on all client machines before you kick off the test is a good idea but isn't crucial because you can reset the LoadSim output results to account for clock inconsistencies. As the tests are running, visually inspect the environment to make sure that the clients aren't reporting any errors and that the servers keep chugging along. LoadSim logs messages to a loadsim.out file as well as to the display, which shows information about the simulations.

After the simulation starts, launch the Counter Logs that you set up earlier, and make sure that they keep running. Be sure to let the test load run for at least 2 hours to achieve steady state and another 4 hours to provide a reliable run. LoadSim might take a few additional hours to shut down and clean up all pending requests. After you run your first test, look for errors to see whether the data is worth keeping. For a few other testing options and information about setting up additional test runs, see the Web-exclusive sidebar "Testing Options and Additional Tests" (http://www.winnetmag.com, InstantDoc ID 24128).

Internet-protocol load testing, which simulates clients such as Outlook Web Access (OWA), is a bit more complex than MAPI-client testing. To test non-MAPI clients and protocols, you need to use other tools—in particular, the Microsoft Exchange Stress and Performance (ESP) tool. In my next article, I'll explain how to use ESP to simulate Internet-protocol clients and how to analyze your LoadSim and ESP test results.