Few things in a typical network are under as much of a workload and consume as many resources as an Exchange server. Because of this, it isn’t at all uncommon to see Exchange’s performance start to decrease under an increased workload. Fortunately, there are things that you can do. In this Daily Drill Down, I’ll discuss some things that you can do to enhance Exchange’s overall performance.

Memory, memory, memory!
The single biggest way to increase your Exchange server’s performance is by adding memory, a lot of memory. Exchange is a glutton when it comes to memory. In fact, one of the questions that I’m asked most often about Exchange is why it consumes so much of a system’s memory.

Exchange is actually designed to consume as much memory as it can without interfering with Windows 2000’s performance. Exchange memory consumption is adjusted dynamically for optimum usage. The idea is that Exchange is going to consume as much memory as possible. After all, what good does it do you to have that 512 MB of memory in your system if Exchange won’t take advantage of it?

At the same time, the developers of Exchange 2000 knew that Exchange had to work around Windows 2000’s memory needs. It doesn’t do any good to have Exchange running smoothly if Windows is continuously paging because of insufficient memory. Therefore, Exchange was designed to not use so much memory that it completely drains your system. If Windows needs more memory, Exchange will release some of the memory that it has consumed, allowing Windows to run at its maximum potential.

To give you an idea of just how much memory consumption I’m talking about, one of my test machines contains 256 MB of memory. During a time when Exchange 2000 was running but was idle, only 24 MB of the original 256 MB remained. This means that Windows and Exchange combined were consuming 242 MB on a machine that wasn’t doing anything.

If you’re curious to see how Exchange dynamically shifts memory usage, open the Performance Console by selecting it from the Start | Programs | Administrative Tools menu. When the Performance Console loads, click the plus sign icon to add a counter. When the Add Counters dialog box appears, select the Memory Performance object and the Cache Bytes counter.

Disk usage
A server’s hard disk configuration is almost as important to the system’s overall performance as the memory. You’re no doubt aware that not all hard drive types are created equal. Some hard drives are faster than others, and RAID arrays that implement stripping perform data read and write more quickly than stand-alone hard drives.

Microsoft recommends keeping the transaction logs on a separate physical drive from the Exchange databases. Doing so increases performance and fault tolerance. Likewise, the Exchange database should exist on a stripe set (or your system’s fastest hard drive) so Exchange can make optimal use of the hard drive’s speed.

If you’ve already installed Exchange 2000 or inherited an Exchange 2000 system, this knowledge doesn’t appear to do you much good, at first. After all, Exchange 5.5 contained a tool called the Performance Optimizer, which allowed you to painlessly move the databases and log files to any location that you desired. Unfortunately, the Performance Optimizer simply doesn’t exist in Exchange 2000. This doesn’t mean that you’re stuck using the present database locations, though. Exchange 2000 still allows you to move databases; the method has just changed.

To move an Exchange 2000 database, open the Exchange System Manager console and navigate through the console tree to your organization | Administrative Groups | your group | Servers | your server | the storage group containing the database, and the select the database that you want to move. Next, right-click the database and select the Properties command from the resulting context menu. When you do, you’ll see the database’s Properties sheet. Select the Properties sheet’s Database tab. This tab contains the locations of the Exchange database and the Exchange streaming database. You can change the location of either database via the Browse button.

Likewise, you can also move the transaction log files. To do so, navigate through the Exchange System Manager console tree to your organization | Administrative Groups | your administrative group | Servers | your server | the storage group containing the database. Right-click the storage group and select the Properties command from the context menu. You’ll then see the storage group’s Properties sheet. The General tab on this Properties sheet contains the location of the log files for that storage group. You can change the location of the log files by clicking Browse.

Before you change the log file location though, there are a few things that you should know. In Figure A, you’ll notice that Exchange has assigned a log file prefix to the transaction log files. This prefix means that any transaction log file associated with the database will start with this prefix number, in this case E00. Because of the use of prefixes, it is theoretically possible to use the same folder to store the transaction logs for each storage group. However, I strongly recommend that you don’t do this. I mentioned that the speed at which your hard drives could read and write data would affect performance. Because of this, I recommend using one set of transaction log files per hard drive (or array). Once you put more than one set on a drive, performance will begin to suffer because the hard disk will be dividing disk access time between two or more sets of transaction logs that need to be processed. On a busy Exchange server, processing a set of transaction logs is no small task.

Figure A
The log file prefix allows you to determine with which storage group a set of transaction log files are associated.

Also, transaction logs are critical to recovering your Exchange databases in a disaster situation. In fact, the transaction log files are so important that Microsoft recommends placing them on a mirrored drive. Therefore, when dealing with the hard disk requirements for transaction log files, you’ve got to consider speed and fault tolerance. You’ll want to use a fast hard disk with nothing else on it for optimum speed, but you’ll want to mirror that drive to provide some fault tolerance. If it’s in the budget, you could use a RAID array for the transaction log files, but this could prove to be overkill and get really expensive, especially if you’ve got more than one storage group on each server.

When you were looking at Figure A, you may have noticed that I had circular logging enabled. In an Exchange 5.5 environment, Microsoft preached against using circular logging unless you simply didn’t have a choice because of disk space restrictions. In Exchange 2000 however, having circular logging enabled is the default setting. According to my sources, Exchange 2000 is optimized to perform better with circular logging enabled. Therefore, if using circular logging makes you nervous, you can disable it, but be advised that performance may suffer in the process.

The Directory Service Access Cache
As you probably know, one of the big selling points of Exchange 2000 is the fact that it takes advantage of the power of the Active Directory. However, as you’ve already seen in this article, Exchange 2000 can become a monster, and if not properly configured, it can bog down the server on which it’s running. What you may not realize, though, is that Exchange 2000 can also place a tremendous load on the Active Directory.

Each Active Directory contains one or more global catalog servers. The global catalog servers provide an index by which Active Directory clients can locate objects within the Active Directory. If you have one or more heavily used Exchange servers, there’s a good chance that you could bog down your global catalog servers with lookup requests.

To prevent such a bog down, Exchange relies on something known as the Directory Service Access Cache. This cache is designed to locally store a record of any Active Directory lookups that the server has had to perform in the last five minutes. To understand why this cache is important, consider what would happen if it didn’t exist.

If you wanted to send a note to someone with a local e-mail account, the Exchange server would have to perform an Active Directory lookup to determine some information about the user object associated with the mailbox to which you’re sending the message. If you then needed to send the person a second note a couple of minutes later, Exchange would have to perform the lookup all over again. Now, imagine thousands of Exchange users hammering the global catalog servers with lookup requests, and you can see how performance problems could result.

By using the Directory Service Access Cache, you can prevent your Exchange servers from having to look up Active Directory information again. The good news is that Exchange is set to use this cache automatically. The bad news is that the entire cache size is only 4 MB. Therefore, in a busy environment, it’s possible to overwhelm the cache, thus making it ineffective. Fortunately, you can assess your organization’s Directory Service Access Cache needs and then fine-tune your cache to match the determined needs.

The first step in the cache optimization process is to determine whether or not the present cache is meeting the organization’s needs. To do so, open the Performance console and click the plus sign icon to add an object. Next, select the MSExchange DSAccess Caches performance object. You’ll then see a list of several available performance monitor counters that you can examine to see how well Exchange is using the cache.

If after examining the cache’s performance, you determine that the cache isn’t large enough, you can increase its size by editing the Registry. You can also boost performance by changing how long entries can remain in the cache before they expire. By making entries stick around longer, you reduce the number of global catalog server queries.

Of course, if you increase the expiration time, you’ll probably have to make the cache larger to accommodate the growing number of concurrent cache entries. You must remember not to set the cache’s expiration time too high, though, or you could run the risk of having Active Directory entries change long before they have been flushed from the cache. All of the cache modifications that I’ve just mentioned can be made by editing the Registry.

Conclusion
Exchange 2000 uses more system resources than many other common network applications. However, it is possible to give Exchange a performance boost by making sure that you have adequate hardware resources available and that the software is configured properly.