The chart is from SCI’s October newsletter/performance dispatch on Exchange 2010 Solution Reviewed Program (ESRP v3.0) and shows the mailbox database access latencies for read, write and log write. For this report we are covering solutions supporting from 1001 up to 5000 mailboxes (1K-to-5Kmbx), larger and (a few) smaller configurations have been covered in previous performance dispatches. On latency charts like this – lower is better.
We like this chart because in our view this represents a reasonable measure of email user experience. As users read and create new emails they are actually reading Exchange databases and writing database and logs. Database and log latencies should show up as longer or shorter delays in these activities. (Ok, not exactly true, email client and Exchange server IO aren’t the same thing. But ultimately every email sent has to be written to an Exchange database and log sometime and every new email read-in has to come from an Exchange database as well).
A couple of caveats are in order for this chart.
- Xiotech’s top run (#1) did not use database redundancy or DAGs (Database Availability Groups) in their ESRPv3 run. Their feeling is that this technology is fairly new and it will take some time before it’s widely adopted.
- There is quite the mix of SAS (#2,3,6,7,9&10), FC (#1,5&8) and iSCSI (#4) connected storage in this mailbox range. Some would say that SAS connected storage should have an advantage here but that’s not obvious from the rankings.
- Vendors get to select the workload intensity for any ESRPv3/Jetstress run, e.g. the solutions shown here used between 0.15 IO/sec/mailbox (#9&10) and 0.36 IO/sec/mailbox (#1). IO intensity is just one of the myriad of Jetstress tweakable parameters that make analyzing ESRP so challenging. Normally this would only matter with database and log access counts but heavier workloads can also impact latencies as well.
Wide variance between read and write latencies
The other thing of interest in this chart is the interesting span between read latencies and write (database and log) latencies for the same solution. Take the #10 Dell PowerEdge system for example. It showed a database read latency of ~18msec. but a database write latency of ~0.4msec. Why?
It turns out this Dell system had only 6 disk drives (2TB/7200 RPM). So few disk drives don’t seem adequate to support the read workload and as a result, show up poorly in database read latencies. However, write activity can mostly be masked with cache until it fills up, forcing write delays. With only 1100 mailboxes and 0.15 IOs/sec/mailbox, the write workload apparent fits in cache well enough to be destaged over time, without delaying ongoing write activity. Similar results appear for the other Dell PowerEdge (#6) and the HP Smart Array (#7) which had 12-2TB/7200 RPM and 24-932GB/7200 RPM drives respectively.
On the other hand, Xiotech’s #1 position had 20-360GB/15Krpm drives and EMC’s Celerra #4 run had 15-400GB/10Krpm drives, both of which were able to sustain a more balanced performance across reads and writes (database and logs). For Xiotech’s #5 run they used 40-500GB/10Krpm drives.
It seems there is a direct correlation between drive speed and read database latencies. Most of the systems in the bottom half of this chart have 7200 RPM drives (except for #8, HP StorageWorks MSA) and the top 3 all had 15Krpm drives. However, write latencies don’t seem to be as affected by drive speed and have more to do with the balance between workload, cache size and effective destaging.
The other thing that’s apparent from this chart is that SAS connected storage continues to be an effective solution for this range of Exchange configurations, following a trend first shown in ESRP v2 (Exchange 2007) results. We reported on this in our January ESRPv2 analysis dispatch for this year .
The full dispatch will be up on our website in a couple of weeks but if you are interested in seeing it sooner just sign up for our free newsletter (see upper right) or subscribe by email and we will send you the current issue with download instructions for this and other reports.
As mentioned previously ESRP/Jetstress results are difficult to compare/analyze and we continue to welcome any constructive suggestions on how to improve.
