What's caching, really?

In the last post I told you that E2K7 (that’s short for Exchange 2007) uses lots and lots of caching to improve performance, especially on 64-bit architectures where lots and lots of memory is available.

One way to improve performance is to keep all data in zippy-fast RAM (random access memory) as opposed to on slug-like hard drives. Trouble with RAM is that when you reboot the machine, all contents are wiped away whereas hard drives can keep everything between reboots. So you can't only use RAM. The other problem with RAM is that there is never enough of it. 16GB is the practical limit of RAM you can load into a reasonably priced machine nowadays, whereas that same machine could take several Terabytes of disk.

So a compromise is needed. That compromise is caching. Caching means "fronting" the slow disk with fast RAM, and it relies on a property of most applications called "locality of access". The actual number of disk pages accessed during any small period of time is much smaller than the total amount of disk, especially with Exchange. Think about the 1GB of data in your mailbox - how much of it do you ever use at the same time? That means that the whole "working set" of disk pages can be mirrored in RAM, if you have enough of it.

On the first read operation, Exchange can bring the 8 KB disk page containing your data (and some nearby data) into RAM. All subsequent reads and writes can occur onto the mirrored page in RAM. When the user moves onto something else 10 or 12 seconds later (an eternity to a CPU running with a 3GHz clock speed) the RAM-mirrored page begins "ageing", and if it is not touched in a while, it is written back to disk so that the RAM can be used to mirror a different disk page that is in more active use.

This technique vastly reduces the number of iops to disk in favor of mops to RAM, which, are much, much faster, and don't require that you pay for all those expensive disk spindles to supply you with your necessary dose of iops.

One caveat with Exchange is that it is a database (albeit a cheesy one, but more on that in another post), and so there is a requirement to write data back to disk. In databases, this is handled by writing changes to the database to a "transaction log" straight to disk without any pesky caching getting in the way. That way, if the server suddenly crashes, the combination of whatever is on the disk plus the transaction log can bring the database right back up to date. So in the case of Exchange, big caches don't save on log write operations, but they sure save on store iops, which are by far the most common operation.

There are other ways of speeding up access to data other than caching, but they all require reorganizing the data radically and moving away from a more standard relational database organization to a super-customized disk organization, specifically geared towards your application. Even then, customized application-driven caching can still dramatically improve matters from there.

Taking a sub-optimal storage layout and throwing a 64-bit address space worth of caching at the problem as was done for E2K7 may not be elegant, but it sure gets the job done

E2K7 Feature Rankings - here’s what you’ve said so far!

Here are the top 11 features of Exchange 2007 according to your rankings so far! Agree? Disagree? Vote at http://www.ceryx.com/exchange2007.asp for your favourites.

Top 3 Features:

Outlook Web Access
Improved Calendaring and Scheduling
Improved Function Management from Mobile Devices

Next 2:

Sharepoint and RSS integration
Outlook Voice Access

Bottom 5:

Better search and message management
Out of Office Privacy and Config Mgmt
X64 Architecture
Native replication
Regulatory Compliance


Check back as we post updates to the survey!

Why x64?

Exchange 2007 is only supported on 64-bit hardware and operating systems. This will cost a lot of people a lot of time and money to replace servers. Why did Microsoft do this? I’ll try to explain the thinking here.

Disk i/o operations per second (iops) is the single biggest constraint in Exchange 2003. A heavy user in E2K3 uses about 1 iops to the disk subsystem. A typical disk drive running at 10,000 rpm can deliver about 100 iops (your mileage may vary depending upon how much caching is in place in the disk subsystem. For example, a SAN will typically cache a lot and give you an effective iops more like 150 for the same disk).

Unfortunately, iops are SLOW, slow like molasses compared to quick in-memory access. An iop needs to wait for disks to spin, and disk heads to move, and processor interrupts, and finally transfers of data over impossibly slow busses. That means that users accessing large mailboxes are slowed way down as well.

The time-honored, brute force solution to slow iops and not enough of them is to keep recently used data mirrored in RAM (called caching). RAM is very speedy and the number of mops (memory operation per second) that can be done is vastly greater. Consider 1066 MHz RAM: that can do 1,000,000 mops. A lot faster than the 100 iops a disk can do (the comparison is a bit bogus because transfer size is not considered, but you get the idea).

Exchange 2003 used as much cache as it possibly could within the confines of a 4GB memory size imposed by 32-bit hardware and operating systems. They even put in a special /3GB switch to tell Exchange to use up to 3GB of cache on a machine configured with 4GB of RAM to tell Exchange that there is nothing else running on the machine and it's ok for it to hog it all like that. So, 32-bit machines are limited to addressing 4GB of memory. 64-bit machines, on the other hand, can address, well, LOTS of RAM (about 17 million Terabytes, which Bill assures us "ought to be enough for anybody", but who's counting).

So by going to 64-bit hardware (which in turns needs an operating system specially compiled and optimized to use the 64-bit hardware) this allows Exchange to make the database cache as large as you can afford.

The difference between a server with 4GB or RAM and one with 32GB of RAM is about $13K. The difference between one with 4GB RAM and one with 16GB is $2K. I think I'll stick to 16GB servers for now, thanks all the same. Microsoft reckons you need 2GB of RAM plus anywhere from 2MB up to 5MB extra per mailbox depending upon how heavy the user is (no fat jokes, please).

So a server with 16GB of RAM can host about 3000 heavy users. 3000 heavy users used to require 3000 iops, which can only be supplied by a whopping 30 disk drives. Definitely expensive SAN territory. And at about $1400 for a 10krpm 300GB Fiber Channel SAN disk drive, that's an extra $42K for disk drives.

Microsoft also reckons that the iops load drops to about 30% of what is was in E2K7. That means that the same storage can be had from fewer, less expensive 500GB 7200 rpm disks, which cost about the same as the smaller faster 300GB drives. We can make do with 18 of these disks instead (or fewer if you venture into RAID5 territory).

So we spend $2K extra for the RAM, but we save $17K on disk drives. Makes sense to me. And it will keep making better and better sense as RAM prices continue to drop, and as the size of disks continue to get larger (for the same $) but spin no faster (hence no extra iops).

Not only is it cheaper, but much larger mailboxes, no longer constrained by the speed of iops, can be used in Exchange 2007, and the same-sized mailboxes are faster to access on loaded servers. All good news.

Couldn’t Microsoft have also put out a 32-bit version of Exchange 2007 to support up to 400 heavy users? Actually, the eval is 32-bits, so it’s clearly possible. Why not support it in production? The cynic might say “sell more hardware and OS licenses?”. As a developer, every extra platform supported costs extra money, and if the world, and especially Longhorn is going 64, well…

So while this is great news if you're going out to buy a brand new Exchange 2007 back-end server, if you have an existing Exchange server you would like to upgrade, chances are it's all wrong for you. Oh well, you needed a beefy 32-bit server for that old accounting package anyways.

Some thoughts from around the industry and the blogosphere on Exchange 2007

Here's an extensive piece in Redmond Mag that reviews some of the same features on our list. (You can rate your favourites here as well.)

Here is a scorecard that contains some interesting insights.

Read any interesting insights on Exchange 2007? Leave a comment or email us at blog@ceryx.com.

Moving to E2K7 from Notes just got easier

Microsoft announced today that companies moving from Notes to Exchange can now download a free migration tool - the Microsoft Transporter Suite. It's a 32MB download and available from the Microsoft site.

Exchange 2007 - Rank the Features!

We at Ceryx talked to our customers and end users and have put together a list of the most significant features and functionality available with Exchange 2007 - from Outlook Voice Access, to autodiscovery for user setup, to compliance and email management features.

InfoWorld issued their own thoughts on features last year. We'd like to hear what you think. You can download our list from this page (contact information required), vote on what you think are the most valuable features, and discuss both rankings by commenting on this post below.

We'll be issuing a ranking based on user votes sometime in May, so please check back.

InfoWorld's ranking of top ten features
Ceryx' ranking (your information will be required to complete download)

Rank the features according to your experience

You Had Me at EHLO - Blog Pick of the Week

We will be making recommendations on blogs that we find useful and informative on a regular basis. Our first blog spotlight is Microsoft's Exchange 2007 team has a blog, You Had Me at EHLO. it's a wealth of information from the Exchange 2007 team on everything from troubleshooting to tips to other links.

This post includes some excellent information on Active Directory design for Exchange 2007.

Welcome to the Exchange 2007 Blog!

Thanks for visiting. We at Ceryx have recently launched this blog to facilitate discussion around Exchange 2007 - what's new, what do you need to be aware of, and how will it impact your messaging environment. This blog will cover everything from:

• Insights from our experts on our experiences working with Exchange 2007
• Useful websites, news and information related to Exchange 2007 implementations and/or upgrades
• Insights from our projects and rollouts on managing Exchange 2007, particularly new features and functionality

We'll be posting a couple of times a week. If you've seen something interesting that you think should make it to our blog, send us a tip at blog@ceryx.com. We welcome your comments and questions!