SolutionBase: Stress Testing Exchange with the Exchange Server Stress and Performance Tool

Figuring out exactly how much hardware you need for your Exchange server can entail a lot of guessing. Here's a tool you can use to simulate your environment so you don't overbuy or underbuy on hardware.

Every time that I have ever had to deploy a brand new Exchange Server into a corporate environment, doing so has made me a bit nervous. The reason is because ordering the server hardware is a bit of a gamble. Microsoft doesn't have any guidelines that tell you exactly what server hardware you are going to need based on the number of mailboxes and / or public folders that will be hosted on the server.

The reason why they don't give you this information is because every organization is different. The server's requirements will vary dramatically depending on how heavily the users use Exchange, and on whether or not the server is performing any additional duties. In the end, you are at the mercy of your own knowledge and experience when you are trying to determine what hardware is right for your new Exchange Server.

The good news is that you don't have to wait until you have users using the server in a production environment to know whether the new server hardware is adequate or not. What you can do is to make your best educated guess as to what hardware will best meet your organizational requirements. When the new hardware arrives, you can install Windows and Exchange Server. After doing so, you can perform a stress test on the server to see how well it holds up during the tests. Assuming that the server performs according to your expectations, you can then start setting up mailboxes. If the server does not perform adequately during the tests, then you know that you need to return the server to the manufacturer and buy something with more power.

This is where the Exchange Server Stress And Performance Tool comes into play. The Exchange Server Stress And Performance Tool is designed to simulate a large number of client connections to an Exchange 2003 Server. Here's how it works.

Author's Note

There is also an Exchange 5.5 / 2000 version of the tool that I will talk about later on. Before I get too deeply into this article, there is one very important detail that I need to mention. In a "normal" Exchange deployment, clients attach to the Exchange Server using Outlook. Outlook communicates with Exchange using the MAPI protocol. The Exchange Server Stress And Performance Tool is protocol based. It does not test mailbox access, but rather how effectively the server can respond to a flood of network requests. The tool is protocol based. You can use it to test communications across a wide variety of Exchange related protocols, but MAPI isn't one of the supported protocols. If you want to find out how Exchange responds to MAPI requests, then you will have to use some other diagnostic tool besides this one.

Since the Exchange Server Stress And Performance Tool can't test MAPI communications, you might be wondering what it is good for. I have found that this tool is especially useful if you have clients who will be accessing the server via SMTP or Outlook Web Access. The tool fully supports testing the SMTP protocol or the WebDAV protocol (used for Outlook Web Access) among others.

Acquiring the Exchange Server Stress And Performance Tool

You can download the Exchange Server Stress And Performance Tool for free from the Microsoft Web site. The download consists of a two and a half megabyte, self extracting executable file.

Installing the Exchange Server Stress And Performance Tool

To install the Exchange Server Stress And Performance Tool, copy the file that you downloaded to an empty folder on the Exchange Server that you want to test. Double click on the file, and then click the Run button when prompted. You will now be asked which folder you want to extract the tool into. Make your selection, click OK, and the various files will be extracted into a sub-folder named Medusa.

At this point, you must double click on a file named MSETUP.EXE, that's found in the Medusa folder. When you do, you will see the Exchange Server Stress and Performance setup screen. Unless you need to change the destination folder, just go with the default settings and click the Install button. The installer will copy the necessary files, register several COM objects, and create an icon on the Start menu.

You will now see a message indicating that the utility needs to create a service account. You don't have to enter a name for the service account, but you must supply a service account password. The service account will be used any time that you run one of the utility's modules remotely. The process of creating the service account can take a couple of minutes to complete, but once the account is created, the tool is finished being installed.

Configuring the Exchange Server Stress And Performance Tool

Although you have installed the Exchange Server Stress And Performance Tool, it still needs to be configured. For the purposes of this article, I will show you how to configure the tool to test the Exchange Server against a flood of SMTP traffic.

Begin by clicking the Start button and selecting All Programs | ESP | ESP. When you do, you will see the ESP console appear (ESP is Microsoft's abbreviation for Exchange Server Stress and Performance). By default, the console will be almost completely empty.

The ESP user interface is object oriented. There are three different types of objects that ESP recognizes; workspaces, hosts, and modules. A workspace is really nothing more than a collection of hosts. For all practical purposes, a host is simply a computer, and a module is the component that's used to run the tests.

Creating a workspace

With this in mind, the first thing that we have to do is to create a new workspace. To do so, select the New Workspace command from the console's File menu. Nothing will appear to happen, but you have created a workspace named Untitled. Select the Save As command from the File menu and you will be prompted to enter a filename for your workspace (the default filename is UNTITLED.INI). For our purposes, let's call the new workspace ESP.INI. When you do, you will see the console updated to reflect a workspace named ESP.

Now that we have created a workspace, we have to add one or more hosts to it. The hosts will be the Exchange Servers that you want to test. Keep in mind that the Exchange Servers that you are testing must be running Exchange Server 2003. There is a separate tool for testing Exchange 5.5 and Exchange 2000. For the sake of simplicity, let's limit our workspace to a single host.

To add the host to the workspace, select the workspace and then select the Add Host command from the console's File menu. When you do, you will see the Add Host dialog box appear. The dialog box, shown in Figure A, requires you to enter

the name of the host, and the domain Administrator's password.

Figure A

Enter the host name and the domain Administrator's password.

You also have the option of limiting a test to a specific duration if you choose to. After entering this information, click the Add Host button (not the OK button). Before clicking OK, you must manually connect to the host that you have added to the workspace. To do so, simply click the Add Host button. Once the host has been connected, click OK to close the dialog box.

Now that you have added a host to the workgroup and connected the workgroup to the host, it's time to configure the host to run some specific tests. As I mentioned earlier, for the purposes of this article, I will be configuring my test server to run an SMTP test. You can use the exact same procedure to test any of the other protocols though.

To configure the host to run specific test modules, right click on the host within the workspace and select the Properties command from the resulting shortcut menu. When you do, you will see the host's properties sheet. The test modules are listed on the Available Modules tab, shown in Figure B. By default, all of the test modules are listed, but none of them are active. Therefore, you must select the SMTP module and click the Add button.

Figure B

Select the SMTP test module and click the Add button.

While you are configuring the modules, I recommend taking a look at the Options tab. The options tab contains four options that you can set. The first option is Max Transport Threads. This option allows you to configure the number of ESP transport threads that will be generated to handle I/O requests. The second option is the Archive Log option. It allows you to control whether the test should generate a new log file or overwrite the old log file. The third option is the Log Results option. As the name implies, it allows you to determine whether or not the test results should be logged. The final option is the log file path. This is the location where the log file will be placed.

Click OK and the SMTP module will be added to the workspace beneath the host. The next thing that you must do is to customize the module to meet your needs. To do so, right click on the module and select the Properties command from the resulting shortcut menu. For the most part, you will be OK using the default values, but you will have to enter a script name and the name of the server that you are running the script against.

ESP allows you to create some pretty elaborate scripts that you can use to test the server's SMTP capabilities. I'm not going to pretend to be some kind of scripting guru. My scripting skills are mediocre at best. Fortunately, there are a lot of sample scripts included with ESP's documentation. Below is a sample scripts (taken from ESP's documentation) that you can use in conjunction with the SMTP module. ESP's documentation contains lots of information about how to modify this script and there are also other example scripts.

Example 1 Send a message with one recipient. The message body is in file body.txt. Sleep between 3 and 5 seconds afterwards.




RCPT TO: someone@somewhere

DATA body.txt




body.txt ends with CRLF.CRLF. You can also use BDAT instead of DATA.

Running the Test

Once the test module has been configured, it's time to actually run the test. You can run the test locally on the Exchange Server that you are testing. However, if you want to get a better feel for how your underlying network infrastructure is performing, I recommend installing ESP onto a different machine and running the test remotely. If you really want to make things interesting, you can even configure multiple computers to run ESP test modules simultaneously against a single Exchange server. The module can only be run against an Exchange 2003 Server, but the ESP console can be run under Windows 2000, 2003, or XP.

To run the test, simply right click on the module and select the Start command from the shortcut menu. Keep in mind that ESP is only going to give you statistics related to the commands that the script is executing (such as the total number of connections). Although ESP is designed for performance analysis, it does not generate any performance data on its own. For that, you will have to run the Performance Monitor against the machine that's being tested. Since we are testing SMTP performance, then I recommend loading the following counters that are found in the Performance Monitor's SMTP Server performance object:

  • Connections Current
  • Local Queue Length
  • NDRs Generated
  • Remote Queue Length
  • Messages Delivered / sec
  • Messages Sent / sec
  • Messages Received / sec

Interpreting the Test Results

Unfortunately, every module has its own individual set of results, so there is no way that I have the space to discuss every conceivable test result. They are however all in the ESP documentation. I do want to take a moment and discuss the results of the SMTP test.

When you run the SMTP test, there are some things that you can look for to determine whether or not the server is performing adequately. For example, you can watch the Remote Queue Length counter to make sure that it is not constantly growing. The Server needs to be able to process messages almost as fast as the messages enter the queue.

Another thing that you should check is the server's event logs. Even if the server seems to be performing adequately, you need to make sure that no errors are occurring behind the scenes as a result of your tests.

Exchange 5.5 and 2000

Earlier I mentioned that ESP could not be used to test the performance of an Exchange 5.5 or of an Exchange 2000 Server. There is however an older version of ESP available that you can use for such tests. You can download this version from the Microsoft Web site.

All that and more

In this article, I have barely even begun to scratch the surface of what you can do with ESP. I strongly recommend looking at the ESP documentation for assistance with testing alternate protocols and with developing scripts that are suitable for your organization.