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

    These profiles refer to the database random I/Os. These profiles do not include all other Exchange-specific I/Os. For example, using these rules, a 3000-mailbox "Heavy Knowledge Worker" server may see average peak random disk I/O to the database drives in the 3000/sec range, and a 3000-mailbox "Average Knowledge Worker" server may see average peak random disk I/O to the database drives in the 1500/sec range.

    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.

    "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.

    For detailed information about how to measure the mailbox profile, see Optimizing Storage for Exchange Server 2003.

  • 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.


Community Additions