Extreme Exchange

It's always fun to take a look around to see how people are misusing (oops, I mean "improving") everyday technologies. A New Zealand inventor's jet-powered beer cooler is one example. (It doubles as a barbecue, thanks to the jet engine's exhaust.) As mechanics and teenage hot-rodders have long done, administrators are taking measures—some of them extreme—to try to boost their systems' performance. Let's look at a few heroic efforts and see whether they make sense for messaging systems.

First on the list is the old-school "there's no replacement for displacement" approach. This school of thought follows the Internet maxim that, given sufficient thrust, pigs fly just fine: If your messaging system is having a performance problem, adding more CPU power is sure to fix it. As administrators, we've all gotten lazily dependent on Moore's Law to bail us out; if an application we manage isn't working well, we try a newer, faster server. Exchange, power-hungry application that it is, responds well to this approach, up to a point. Most of the important components are multithreaded, so they can take advantage of multiple CPUs. For example, the SMTP transport engine, Active Directory (AD), and Microsoft IIS—critical components all—are fully multithreaded. Even multithreaded applications have their limits, though; Microsoft's scalability white paper says that, in most cases, Exchange performance doesn't scale beyond four processors. If four processors aren't enough to handle your servers' workload, you probably need some new servers—additional servers, not replacements. However, when you're considering beefing up a server's CPU power, make sure you first use Performance Monitor to watch its disk I/O performance and RAM utilization, or you might find that the CPU you've augmented wasn't really the bottleneck.

Next, a word about RAM fiends. If someone tells you, "You can never have too much RAM," you're in the company of a bona fide RAM fiend. Because RAM has become so cheap, some administrators have gleefully loaded their servers with as much RAM as will fit—4GB or more isn't uncommon. Again, the Exchange design team anticipated that one day we'd all have hundreds of megabytes of RAM at our disposal (quite a stretch, considering the average amount of RAM available for servers when Exchange originally shipped), and Exchange can productively use large amounts of RAM through a technique called Dynamic Buffer Allocation (DBA). The idea behind DBA is simple: If a machine has unused physical RAM, Exchange will put it to work, releasing it if the system's page fault rate indicates that some other application is being starved. However, the maximum amount of RAM that Exchange and Windows together can productively use is about 3.8GB, meaning that adding more than 4GB of RAM is a waste. And you won't get the full benefit of 4GB of RAM unless you use the /3GB switch in the boot.ini file, but that switch requires that you run Windows 2000 Advanced Server (Win2K AS).

Finally are the folks I like to think of as hot-rodders. They replace individual server components with faster (and usually more expensive) ones in an attempt to eke out the last iota of performance. For example, administrators increasingly are using RAID1+0 arrays with Exchange because they combine the data-recovery benefits of mirroring with the screaming performance of disk striping—even though such arrays give you only half the capacity you've paid for. Another example is a site I know of that uses a mirrored disk for Exchange data. That might not seem like a big deal, except that one of the disks in the pair is a solid-state RAM disk and the other is a conventional disk. By using VERITAS Software's Volume Manager, the site's administrators can designate which mirrored disk should be used first for I/O operations, so Exchange I/O requests go to the RAM disk first. Still another example is people who add Secure Sockets Layer (SSL) accelerator cards to their servers. Although these cards certainly accelerate SSL transactions, the accelerators don't really pay for themselves until you approach 100 SSL handshakes per second—a mark most Outlook Web Access (OWA) servers will never reach.

Although you can certainly post impressive performance gains by throwing gadgets or horsepower at your Exchange systems, the superior approach is a measured one: Monitor your systems' performance over time to identify exactly where the bottlenecks are, add capacity to fix them, then measure the success of your efforts. This approach isn't as much fun as hot-rodding, but in the long run it's more effective. Now, if you'll excuse me, I have to go shoehorn a V-8 long-block engine into my wife's minivan—it's just not quick enough off the line.