Planning the Jetstress Performance Test
Topic Last Modified: 2007-07-16
This topic describes how to use Jetstress to measure the performance capabilities of a disk subsystem slated for Exchange database and log files. Consider the following factors when you design a Performance test.
- Storage Groups-Databases/Server To adequately measure disk performance, you must configure Jetstress to match the proposed Exchange production configuration for Storage Group and Database count/file location. For example, if the production Exchange server will have four storage groups (four database logical drives and four log logical drives), Jetstress should be configured in the same manner.
- Multiple Servers/SAN Storage Area Network (SAN) technology enables multiple servers to use the same storage hardware. To obtain an accurate measurement of the storage performance, you must run Jetstress on all servers that are attached to the same physical storage devices. For example, if four Exchange servers are attached to the same SAN, you should run Jetstress on each server in tandem to measure the performance. Each server can be configured to run Jetstress differently depending on the number of storage groups, proposed load/user profile, and so on.
- Importance of Database Size It is important to create Jetstress databases that are matched appropriately to the expected database sizes in the production environment. Generally, the larger the Exchange database, the slower that the disks respond to read and write requests.
In the disk subsystem throughput test scenario, Jetstress reserves 25% of the initial database file size for its future growth during a test run. For example, if you decide to size a database at 100 percent of the storage capacity of 100 GB, Jetstress creates initial databases of 80 GB and reserves 25% of the 80 GB (20 GB) for the database file growth.
In the Exchange mailbox profile scenario, you have to consider reserving some free disk drive space for the database file growth on your own. For example, if you choose mailboxes of 500 and mailbox size limit of 1024 MB, Jetstress creates an initial database of 500 GB and you may have to reserve some free disk space for the database file growth depending on the length and intensity of database transactions of a test run.
- Users and Profiles The Exchange client usage profile is a primary factor in determining an appropriate disk subsystem for Exchange. Many client actions that are performed every day can have a significant effect on the load generated against the disk subsystem. Larger average message sizes can also significantly affect the load.
For Exchange Server 2003, we recommend that you determine the mailbox profile before measuring the disk subsystem performance. If the mailbox profile is unknown, some general rules can be used to help size disk performance for the Exchange server deployment. For example, extensive mailbox profile analysis has shown trends about the number of random Exchange database IOPS (disk transfer I/Os per second) per mailbox during peak load. The following rules apply only to the number of random I/Os being generated on the database drives.
Heavy Knowledge Worker Profile= 1 IOPS
Average Knowledge Worker Profile= .5 IOPS
Light Knowledge Worker Profile= .2 IOPS
For Exchange Server 2007, see Planning Processor and Memory Configurations for information about how to plan storage for Exchange 2007 standard I/O profiles. Also, for overall Exchange 2007 disk storage information, see Planning Disk Storage.
For detailed information about how to measure the mailbox profile, see Optimizing Storage for Exchange Server 2003.
Note: "Average Peak" is used in the examples mentioned to show the average database I/O during the peak hours of the day (for example, 8:00 a.m. to 10:00 a.m.). This is the random disk I/O load the database drives must be able to handle over a matter of hours. Do not confuse "Average Peak" with disk I/O spikes. Also, the IOPS value that is used for Jetstress testing must be increased by 20% to allow for spikes, For example, if measured IOPS per user is 1, use 1.2 in the Jetstress test configuration.
- Heavy Knowledge Worker Profile= 1 IOPS
- Exchange and Data Replication If a business requires that the Exchange organization be able to function continuously even if a site disaster occurs, you can increase the reliability of the Exchange data by implementing data replication technologies into your topology. Such data replication technologies are frequently based on geographically dispersed clusters and/or involve a storage area network (SAN)/software-based data replication (for example, keeping multiple SANs in sync over long distance fiber or IP networks). The replication in these solutions is either synchronous or asynchronous.
Synchronous replication Solutions that include synchronous replication technologies can help you achieve 100% data reliability. Synchronous replication technologies write to both storage platforms (both the primary and the replicated storage device) before responding to the operating system that the write was successful. Depending on the distance between the two storage platforms, this latency can be significant (+50 ms). This increased latency creates a load on the server that severely affects the Exchange client experience.
We recommend that you test your storage subsystem with Jetstress where the storage subsystem is configured with storage-based replication options configured. This would be based on the end deployment. For more information, see the Microsoft Knowledge Base article 895847, "Multi-site data replication support for Exchange Server." Additionally, see Deployment Guidelines for Exchange Server Multi-Site Data Replication.