Can your new Exchange server handle the amount of e-mail you want it to? How do you know? Here's how you can use Jetstress to test your Exchange Server.
Imagine for a moment that your company is in need of a new Exchange Server and your boss tasks you with picking out and ordering the new server. You do your homework and find a server that looks like it will get the job done, but that costs a few bucks less than some of the higher end servers. After all, saving money will score some points with the boss, right? Soon the new server arrives. You quickly deploy Exchange and start setting up user mailboxes on the server. Much to your horror though, your bargain basement server can't seem to keep up with the workload that is being placed on it.
Finding out that a server isn't up to the task at hand after the server has been placed into a production environment is bad news. Anyone can make a mistake and order a server that isn't quite up to par, but you need to test your servers prior to placing them in a production environment. That way, if a problem does show up, you can return the server to the manufacturer and get something more suitable for your environment. Some people might get a little upset with you for the delay involved in getting a new server, but at least you haven't put yourself into a situation in which users are actively using the server, and the server does not contain any data.
There are lots of different methods that you can use to test a server's performance. It's usually best to base your testing on the server's role. If the server is going to be running Exchange Server, then one of the most important things that you can test is the disk subsystem. Exchange Server is a very disk intensive application and if your server's disk resources perform on a sub par level, then you can be sure that Exchange will also suffer from poor performance.
Fortunately, Microsoft makes a tool specifically for testing the disk subsystem performance on an Exchange Server. The tool is called Jetstress. In this article, I will show you where to get Jetstress and how to use it to test your new Exchange Server.
You can download Jetstress for free from the Microsoft Web site. The download consists of a 235 KB, self extracting executable file.
Before I start showing you how to use Jetstress, I want to point out that although the Jetstress tool has been around for years, this is a relatively new version (the file is dated 4-6-2005). Even if you have an older version of Jetstress available, I recommend taking the time to download this version. Traditionally, Jetstress has always been a command line tool. However, this version also offers a GUI interface. The GUI interface allows you to do a couple of things that you can't do from the command line. It has also been designed to make testing the Exchange Server's disk subsystem and interpreting the results a whole lot easier than it would otherwise be.
The current version of Jetstress works only with Exchange 2000 and with Exchange 2003. Likewise, it requires your server to be running either Windows 2000 Server (with Service Pack 4 or higher) or Windows Server 2003.
Installing and Configuring Jetstress
As you might expect from a file that's only 235 KB in size, Jetstress does not have much of a Setup program. Simply download the utility and run it. The installer will prompt you for a location to install Jetstress to. What ever location you choose, make sure that it is on one of your server's local hard drives. For some reason, Jetstress does not like running from a network drive.
The next step in the process is to install Exchange onto your server if you have not already done so. Make sure that you arrange the various components (databases, transaction logs, etc.) into the locations where you are planning on using them when the server is eventually moved into your production environment. You should also go ahead and install any service packs that you plan on using on the server.
The reason why we had to go ahead and install Exchange at this stage of the deployment is because Jetstress does not actually contain all of the files that it needs in order to be functional. Jetstress has to borrow four files from Exchange Server; ESE.DLL, ESEPERF.DLL, ESEPERF.INI, ESEPERF.HXX. By default, these files are located in the C:\Program Files\Exchsrvr\Bin folder, although the location may differ if you have installed Exchange Server using a custom path. Copy (do not move) the ESE.DLL, ESEPERF.DLL, ESEPERF.INI, and ESEPERF.HXX files from the \Program Files\Exchsrvr\Bin folder to the folder that you have extracted the Jetstress files into.
Now, try running Jetstress by double clicking the JetStressUI.exe file. This will load the GUI version of Jetstress. When you do, Jetstress will perform a diagnostic check against itself to verify that all of the necessary files are in place. More than likely, you will receive an error message stating that the advanced database performance counters are not enabled. However, you can fix the problem by simply clicking the Fix Errors button (Don't you wish that every application had a Fix Errors button?).
Click the Continue button and you will be taken to the main Jetstress screen, which is divided into a Configuration tab and an Advanced tab.
Configuring Jetstress for the testing
Now, let's start to configure Jetstress for our first test. There are actually two different types of tests that Jetstress can run. The primary test is the performance test. The performance test can be configured to run for anywhere from two to ten hours. During that time, Jetstress will hammer the server with disk I/Os at a level similar to what is expected in real life.
The other test is the disk subsystem test. The disk subsystem test runs for roughly twenty-four hours and is designed to help test the reliability of your disk sub system. Regardless of which type of test you are running, the only thing that Jetstress does is simulates a real life workload. You will have to use the Performance Monitor to see how well the server is actually holding up to the tests.
The first portion of the Configuration tab is the Jetstress test section. This is where you select the type and the duration of the test that you want to run. By default, Jetstress is configured to run a performance test for two hours. You can adjust the test duration by selecting a different amount of time from the Hours drop down list.
Just beneath the Jetstress Test section is the Select Database section. In this section, you must choose whether you want to create a database specifically for testing purposes, or if you would prefer to use an existing database or a backup database. I recommend creating a database specifically for the test. That way, when the testing is done, you can blow away the test database and not have to worry about reconfiguring Exchange before you start adding production mailboxes.
Just below the Select Database section is the Simulate Exchange Server User Profile section. This section is really the heart and soul of Jetstress, and it needs a little bit of explaining. The whole idea behind this section is that you want to configure the Jetstress database to behave as similarly as your real life database as possible. If the server that you are testing will eventually serve as a replacement for an existing server, then filling in these settings shouldn't be too tough, because you should already know the database size, number of mailboxes, etc. For the purposes of this article though, I am going to assume that you are testing a brand new server that will be added to your Exchange infrastructure rather than replacing an existing server.
Normally, when I write this type of article, I like to go through the various configuration options in the order that they are presented within the application. In this particular case though, I think it makes more sense to approach the configuration in a different way. I personally recommend starting the configuration process by setting the Number of Mailboxes on Server variable.
If you plan on eventually adding this server to your existing Exchange Server organization, then you probably have a pretty good idea of how many mailboxes the server will initially have to support. I recommend adding ten percent to the anticipated number of mailboxes just to give yourself a margin of error and to plan for future growth. If you want, you can even start by using the anticipated number of mailboxes plus ten percent, but then run the test multiple times, increasing the number of mailboxes during each test so that you can see what impact future growth will have on the server's performance.
The next thing that we need to establish is the average number of I/O operations per second per mailbox. Before I show you how to come up with this number, there is one very important thing that I need to mention. Jetstress will base its testing on the number that you specify here. The formula that I am about to show you assumes that the server is acting solely as a mailbox server. If the server is also hosting public folders, then the calculations in this article are going to be way off. You would therefore have to increase all of the numbers in the Simulate Exchange Server User Profile section to compensate for public folder usage. To keep things simple, I am assuming that the server is only functioning as a mailbox server.
To determine the appropriate number of I/O operations per second per mailbox, you need to know how heavily your users will be using the server. I recommend taking an educated guess as to how many of your users will be heavy, medium, and light e-mail users. For example, suppose that you estimated that there would be a hundred mailboxes on the server. You might then go on to estimate that ten of the users would hardly ever use e-mail, and would therefore be light users. Fifteen users might use e-mail very heavily, and the other seventy-five users would use Exchange at a medium level.
Now, we can just plug in some I/O statistic numbers. A heavy user will generate about 1 I/O operation per second. A medium user will produce about 0.5 I/O operations per second, while a light user will average about 0.2 I/Os per second. Now, just add up the total anticipated number of I/Os per second and then divide them by the number of user mailboxes. In this case, the math would look something like this:
- 10 light users multiplied by 0.2 I/Os equals 2 I/Os per second
- 75 medium users multiplied by 0.5 I/Os equals 37.5 I/Os per second
- 15 heavy users multiplied by 1.0 I/O equals 15 I/Os per second
When you total these numbers together you get 54.5 I/Os per second. Since there are a hundred users, we divide this number by one hundred and get an average of 0.545 I/Os per second per user.
As you will recall, earlier I recommended that you increase the actual number of mailboxes by ten percent to give yourself a margin of error and to compensate for future growth. You should base the calculations for finding the average I/O rater per second on real mailboxes. For example, in my calculations above, I was assuming that I had a hundred actual users. I would enter 110 for the number of mailboxes on the server since I am adding ten percent to the actual number of mailboxes, but I used an actual mailbox count when determining I/Os per second.
OK, as if your head isn't spinning enough, you must now figure out the size of the Exchange database. Yes, I know that there isn't actually a field that asks you for database size, but in reality, you are building an Exchange database based on the numbers that you input and you need to try to make sure that the test database is about the same size as the anticipated real life database.
Jetstress uses the Mailbox size limit to determine the size of the Exchange database. The idea is that if you plan on using mailbox quotas, you can enter the number of MB that are allocated to each user. Jetstress will then multiply the quota size by the number of mailboxes to determine the database size. For example, if you have 110 mailboxes (remember the ten percent rule) and you have a quota of 100 MB, then the resulting database size (110*100) would be 11,000 MB. That translates to 10.7 GB (11,000 / 1024). Actually, it isn't quite that simple though for several reasons.
One reason is that you are not obligated to use mailbox quotas. If you choose not to use quotas, then you will have to figure out the average mailbox size for each user. One way of coming up with this number is to look at the other Exchange Servers in your organization. Try to look at the average mailbox sizes for light, medium, and heavy users so that you can come up with a weighted average.
Another reason why things aren't so simple is because even if you do mandate mailbox quotas, not every user will reach the quota limit. This isn't really a problem though because Jetstress will just assume that every user will max out their mailbox and will run the test accordingly.
The final reason why things aren't as simple as they seem is because you have to adjust for Jetstress overhead. Jetstress does all of the math for you, but you need to know what's going on because your database sizes won't be what you would expect. Fasten your seatbelts though, because this is about to get a little bit rough.
Earlier, we estimated that we were going to have 110 mailboxes at 100 MB each, for a grand total database size of 11,000 MB. The problem is that Jetstress places a 66% overhead on the databases during the test. That means that if Jetstress set the database size to 11,000 MB and ran the test, that database would balloon up to 18,260 MB. Obviously, you don't want to test disk performance against an 18,260 MB database if you never expect your maximum database size to exceed 11,000 MB.
The other thing that you need to take into account is that a Microsoft recommended best practice is that you always leave 30% of the disk space free on volumes containing Exchange databases. To compensate for the 66% overhead and the free disk space requirement, Jetstress reduces the anticipated database size by 25%. In this case, if our maximum database size was going to be 11,000, then Jetstress would adjust the database size to 8,250 MB. Keep in mind though that this is just the database's initial size. Microsoft recommends multiplying this number by 1.67 to determine what size the database will grow to during testing. In this case, the database will grow to 13,777.5 MB during the tests.
Now that you have calculated the necessary statistics, you have the option of setting the number of storage groups that will be used or running the Exchange database on a NAS device if necessary. When you are satisfied with your configuration, just click the Run button to start the testing.
Stressing the important points
Jetstress only stresses the server. It does not take any benchmark data on its own. You will have to use the Performance Monitor for that. I recommend running the Performance Monitor from another machine so that you will get more accurate results. The reason for this is that if you run the Performance Monitor locally, you will consume unnecessary system resources and skew your results.
I also recommend that when the testing is done, that you check your event logs. There could be a problem that isn't obvious, but that is revealed by studying the server's event logs.