Load Testing Exchange 2000: Analysis and ESP

In the main ESP interface, right-click a protocol module—the examples in this article use DAV to simulate OWA clients—then select Properties to open a dialog box such as the one that Figure 3, page 74, shows. Find Server in the Parameter column, then click the corresponding entry in the Value column and type in the name of the front-end Exchange server that you'll connect to. To test OWA, make sure that the corresponding value for the Authentication Method parameter is BASIC and enable that authentication on your front-end Exchange server. Find the Script File (or Script Path for all modules except DAV) parameter, then click the corresponding value and enter the name of the script that the module will run. To search for the script, double-click the corresponding Value field to display an ellipsis (...) button, then click the button. Because of a minor bug, ESP doesn't show you the script files as you browse. To see a list of files, locate the proper directory, then enter an asterisk (*) and press Enter. You then can see and choose from the files. If you haven't created your scripts yet, simply enter a filename, then save the scripts under that name later.

Repeat these steps to configure each protocol module that you want to use. You don't need to test all the available modules, although if you test IMAP4 and POP3 clients, you should also use the SMTP module because those clients typically use SMTP to send email.

Listing 1 provides a sample script for testing SMTP clients. (I modified this script from samples provided in the ESP documentation. Listing 2 provides another modified sample for testing IMAP4 clients. I suggest that you read the ESP documentation to determine which commands to use to customize the scripts for your environment.) The sample script that Listing 1 shows connects to the Exchange server, then uses the HELO command to identify itself as the user Admin. The script sets the Reply address to sender@company.com, then uses ESP's looping capability to generate a random number of messages between 100 and 1000.

The script then uses a random number (between 1 and 2000) of users you've created. Alternatively, you can use the RANDLIST(userlist.txt) command, where userlist.txt contains the list of accounts you created for your LoadSim tests, to configure the script to pull names out of an exported AD list. (Whereas LoadSim handles the creation of user accounts in AD, ESP doesn't. You can either populate AD manually or through a third-party utility, or you can use the accounts that you created during your LoadSim tests. This approach might be the easiest; you simply export a list of the accounts to a .csv file, then paste the relevant account information into the userlist.txt file for use with ESP. To further simplify the process, first create an organizational unit—OU—in AD, then move the ESP test accounts to that OU.)

Next, the script directs ESP to pull a random message from the msglist.txt file, which Listing 3, page 75, shows. This file contains a list of MIME messages of varying sizes. (To use the sample script, you need to create all these files.) I use Outlook Express to save a message as a .eml file, then rename the file with a .txt extension. (You could also turn on SMTP archiving and capture .eml files.) Then, delete or add blocks of text to adjust the text file to the desired size. You can also define attachments to send with your test messages. ESP scripts can randomly select messages from msglist.txt.

Finally, the script uses a SLEEP command, followed by a random interval (in milliseconds), to help control the duration of the script's cycles. ESP loops the script, repeating the commands as often as it can and waiting only for the specified sleep cycles, which are the key to simulating real-world client loads. If you don't build in enough sleep latencies, client processor utilization will climb to 100 percent and you'll have trouble controlling the client machine to stop the script. To determine how often to insert a SLEEP command, think about how your users access your Exchange servers. IMAP4 or POP3 clients might poll the Exchange server for new messages every half hour. Users who are actively working at the computer might read their email messages, respond to a few messages, and create a few new messages. You can use these activity intervals to determine the sleep intervals to use in the ESP scripts. OWA clients might remain connected to the Exchange server all day, so your ESP script should connect once and periodically check for new messages during the day. (If you use OWA 2000, which comes with Exchange 2000 Service Pack 2—SP2, you'll need to update your ESP scripts to simulate the functionality of OWA 2000's updated features.)

To run the load simulation, select a host and click Start Module(s) or select a module and click Start Modules(s)—or right-click the module, then select Start. The latter methods give you complete control over how many modules you want to run at the same time. Be aware that once you begin a test, you can't click Stop Module to stop a module until the module icon turns green (indicating that the module is running). If you try to use this button before the module is running, you might need to close and restart the entire ESP client. Unlike LoadSim, ESP doesn't generate any client response measurement, so the only performance statistics you can gather are those you capture through Performance Monitor. (See "Load Testing Exchange 2000" for instructions about how to capture that data.)

Get the Big Picture
Analyzing your LoadSim results provides a good picture of your Exchange servers' performance in relation to MAPI clients such as Outlook. For an analysis of any Internet-protocol clients, the script-driven ESP utility provides similar functionality, although these protocols' lack of a standard profile such as MAPI Messaging Benchmark (MMB) 2 means that you must rely solely on Performance Monitor data captures to determine whether the load that ESP generates accurately represents your desired test load. With LoadSim (and its built-in analysis utilities), ESP, and Performance Monitor, you'll soon have a solid idea of the strengths and weaknesses of your Exchange servers' performance.