Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 9)

By /

If you would like to read the other parts in this article series please go to:

Testing Disk Performance Continued

With Exchange Server 2013 comes a new version of JetStress with a bunch of new improvements and customizations making it the best version of JetStress yet. While there’s some big changes under the hood, the user interface changes are subtle, but important. As we go through the install and setup, where you’ll see a few changes from the steps used for 2013.

Installing JetStress 2013

We’ll get started by downloading JetStress 2013 from the Microsoft download site.

After downloading JetStress 2013 to our Exchange 2013 server, we’ll install using the standard options, much as we did for JetStress 2010.

Image
Figure 1: Installing JetStress

In our example we’ve installed to the default location. As with JetStress 2010, it makes little difference where it is installed, but if you use a different location ensure you note the directory path as we will need to copy files into the installation location in a few moments.

Locating JetStress 2013 ESE Files

Earlier in the series we extracted the Exchange 2013 installation files from the downloaded Cumulative Update compressed package. These will now come in handy as we’ll use them as the source of the files JetStress will use for the ESE database engine to run the tests with.

To locate the files, navigate to the setup\serverroles\common folder within the extracted folder and locate the ese.dll file:

Image
Figure 2: Locating ESE DLL Files

Next, navigate into the perf\amd64 folder and locate the eseperf.dll, eseperf.hxx, eseperf.ini and eseperf.xml files:

Image
Figure 3: Locating ESE performance counters

Copy all these files into the location you’ve installed Exchange JetStress 2013 into, which in our example is C:\Program Files\Exchange JetStress:

Image
Figure 4: Copying Exchange ESE files to the JetStress 2013 installation folder

After copying the files into the right location, we’ll launch JetStress 2013 just the once to register performance counter and ensure it can locate the ESE DLL files:

Image
Figure 5: Getting JetStress 2013 ready

After launch you’ll see This process must be restarted for the changes to take effect. Choose Exit to close JetStress.

Configuring JetStress 2013 for first run

With JetStress 2013 installed correctly with the Exchange 2013 engine files, we’re now ready to configure JetStress for its first run.

Re-launch JetStress 2013, and after verification it can still locate and load the engine, choose Next:

Image
Figure 6: Starting JetStress ready for configuration

We’ll then be given the choice to create a new configuration file or use an existing one. We can’t use the configuration file from JetStress 2010 – and the settings are different – so we’ll choose the Create a new test configuration, then choose Next:

Image
Figure 7: Creating a new configuration file

On the next page, we’ll choose the same option we used for JetStress 2010 – Test disk subsystem throughput:

Image
Figure 8: Defining the test scenario

We will then define how much data we’re going to put onto the disks, and how hard we’ll push them. Here we use different settings to JetStress 2010 as we’ll use both 100% for capacity and IOPs, but we will not need to go through the iterative steps for finding the maximum thread count to use, so we’ll unselect Supress tuning.

Image
Figure 9: Selecting the capacity and throughput

Next we’ll move onto the test type selection page. Select Performance for the type, then we’ll ensure that Multi-host test is selected. We’ll choose this option in particular because we’re building out environment on a virtual platform. We’ll also make sure Run background database maintenance is selected too, then choose Next:

Image
Figure 10: Selecting the type of test

On the Define Test Run page we’ll leave the Output path as its default, and for the first run we’ll set the test duration to just 2 hours. As with the JetStress 2010 test we will revisit this later to extend the test duration:

Image
Figure 11: Defining the test run

Next we will define our database configuration. As this will mimic our production databases it is critical that the databases and log locations defined here match the exact configuration we’ll use for the actual deployment. In our example below we’ve defined our databases and log locations:

Image
Figure 12: Defining the database and log locations

We’ll now need to create the test databases that will support the test. Although they’ll be similar in size and share naming conventions with our JetStress 2010, we can’t copy them across and just use them. We’ll need the Exchange 2013 version of the ESE files to create the databases for us, so we’ll choose Create new databases:

Image
Figure 13: Creating new databases for the test

On the Review and Execute Test page we’ll be presented with a summary of the settings we’ve chosen. Double check everything is correct, especially the database and log locations, then choose Prepare Test:

Image
Figure 14: Double checking settings before test preparation

Expect the preparation for JetStress 2013 to take a while – for example if you are using 2TB databases, at least 2TB of random data must be generated and then duplicated.

Executing JetStress 2013

With preparation for JetStress 2013 complete, it’s time to move onto the first (of a few) JetStress tests. Begin the first run by choosing Run Test:

Image
Figure 15: Executing the JetStress test

As with JetStress 2010, a 2 hour test will also have a start-up time, and then log analysis lead-out time as the test concludes. After the test, as well as the raw data we’ll be able to see the performance summary – which is what we’re interested in. To view this locate the HTML file with the prefix Performance and click to launch in a browser:

Image
Figure 16: Locating the performance test results

Interpreting JetStress 2013 Test Results

As with the 2010 results, we’re only interested for our purposes in certain information. We’re looking to see the evidence that the underlying storage subsystem is capable of providing the performance required by the Exchange.

The first area of concern, naturally is to see whether the overall test passed:

Image
Figure 17: Reviewing the overview figures

Assuming the test passes, then we’re onto the figures that really count. Our headline figure is the Achieved Transactional I/O per Second within the Database Sizing and Throughput section:

Image
Figure 18: Examining the overall IOPS

We’ll look further down, underneath Total I/O Performance and look at both the sum of I/O Database Reads/sec and Writes/sec, and after totalling those two columns up do the same with the I/O Log Reads/Sec and Writes/sec:

Image
Figure 19: Reviewing the DB and Log IOP figures

We’ll then compare those figures with the Role Requirements tab of the Exchange 2013 Role Requirements Calculator’s Database and Log IOPs column. You’ll see in our example we passed with flying colours:

Image
Figure 20: Comparing figures against the Exchange 2013 Role Requirements Calculator

What happens if the JetStress tests fail?

But what happens if you don’t meet these requirements, or the test fails?

If the test fails but the IOPs available were high, then it might be time to step back from the auto-tuning uses above, and re-run the test with auto-tuning suppressed, starting with a thread count of 1. As you’ll see from the figures above – the performance required is far lower than is actually available.

If the test fails and the results were borderline or below the actual requirements – and the underlying storage matches the input and output to the Role Requirements Calculator, then it may be time to look at other factors. We won’t cover these in their entirety here – but possible culprits range from inadequate throughput available on an iSCSI network, RAID controller problems to disk firmware issues.

Finally, if you are able to, after a successful test – consider re-running your tests in a disk failure scenario. This should include after the loss of a disk within a RAID array, and during a RAID rebuild. Typically you’ll expect your Exchange system to be online during that process, so it’s worth knowing whether it will meet the demands of your users while you make inevitable repairs.

Performing additional testing

After running your initial JetStress test, the next stage is to ensure that you re-run both tests, concurrently (if you are on a virtual, shared platform), to ensure that your infrastructure can support both Exchange 2010 and Exchange 2013 with active mailboxes at once. We’ll revisit the Define Test Run page of each version of JetStress and ensure we run for a minimum of 24 hours:

Image
Figure 21: Performing a 24-hour run

Uninstalling JetStress 2010 and 2013

With successful JetStress tests completed we’ll need to perform a final step on each server, uninstall JetStress:

Image
Figure 22: Uninstalling JetStress 2010 and 2013

We’ll make sure this is done now on both servers, as part of the uninstallation process the performance counters registered will be uninstalled. We’ll want to do this before installing Exchange 2010 or 2013 to ensure it doesn’t interfere with performance counters Exchange subsequently installs.

After uninstallation of JetStress, don’t forget the other crucial task – cleaning up the databases and log files. Navigate to each Database and Log path and remove the ESE and LOG files created by both versions of JetStress.

Summary

In part nine of this series, we’ve completed two rounds of concurrent JetStress testing. We’ll move onto getting clients ready in part ten of this series.

If you would like to read the other parts in this article series please go to:

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top