So far in this series, I’ve discussed how factors such as network topology, the disk subsystem, memory, and CPU configuration can all affect Exchange Server’s performance. Once you’ve got the network topology and the server’s hardware up to par, however, there are many other factors that affect Exchange Server’s performance.
In this Daily Drill Down, I’ll discuss some of these remaining factors. Some are network related, while others pertain to Exchange itself. You might have noticed that so far everything I’ve talked about doing to enhance performance has been nonquantifiable. Next month, I’ll conclude this series by showing you how to measure how much performance gain you’ve really achieved.
In Exchange Server, the Mail Transfer Agent (MTA ) is one of the most demanding subcomponents. The MTA is responsible for moving messages in and out of the Exchange server. The word “messages” can be deceptive, however. It’s easy to think of messages as mere e-mail messages. The MTA actually does much more than that. Sure, it passes e-mail messages back and forth between Exchange servers within a site, but the MTA also interacts heavily with the various connectors, such as the Internet mail connector, site connectors, and directory replication connectors. None of these connectors will function unless the MTA is running.
OK, so the MTA is important, but why is it so critical to the MTA for you to have the network, disk subsystem, and CPU optimized? To answer this question, consider the way that the MTA works with Exchange Server. Remember that the information stores are in a Jet database format and exist within .EDB files. Now consider that the MTA doesn’t send messages as subsets of the databases. Instead, messages are sent and received in other formats, such as RPC, POP3, or SMTP. The form that the messages take depends on the type of message.
Catch up on the series
Optimizing Exchange Server, part 1
Optimizing Exchange Server, part 2
Optimizing Exchange Server, part 3
When a user sends a message, the message is normally sent directly to the appropriate database file, where it waits to be sent. During the next sending cycle, Exchange translates the message from its existing format into whatever format is necessary for the sending process. This translation process eats up CPU cycles.
Once the translation process completes, the message is added to the MTA queue. The MTA queue is an area on your hard disk where messages sit and wait for the network to have enough free bandwidth and for the Exchange server to have enough free resources to send them.
The MTA goes through this process for every single outbound message. The resources mentioned are also heavily used for inbound messages. As you can see, the MTA is very resource intensive, and the three major factors that I mentioned can definitely impact one another and the rest of the system. For example, if your server is connected to a slow or heavily congested network connection, the MTA queue will get backed up with messages that are waiting to be sent.
This means that as the MTA queue backs up, your hard disk is filling up. Trust me when I say that you really don’t want this hard disk to fill up, because it can cause some nasty side effects. Likewise, having the MTA queue stored on a slow hard disk can cause delays in messages coming in and going out. Finally, if you have a slow CPU, the CPU could become so bogged down with servicing the MTA that other less critical (but more noticeable) functions begin to suffer.
Optimizing the MTA
If the MTA is such an important piece of Exchange and can so easily drain your system of its precious resources, you may be wondering what you can do to limit the MTA’s effect on the rest of the system. Fortunately, there are several things you can do.
First, as I mentioned in “Optimizing Exchange, part 3,” make sure that your system has adequate processing power and an adequate L2 cache. Second, you’ll have to address the issue of network bandwidth. There are several things you can do to improve network performance.
First, you can implement a dedicated connection between Exchange servers within each site. To do so, place a second network card in each server and run cables from each server’s second network card to a dedicated hub. This “second network” should in no way be connected to the primary network. This means that your dedicated hub shouldn’t be linked to any other existing hubs.
Likewise, you shouldn’t use the Enable Routing option within Windows NT. By creating a dedicated connection (commonly known as a backbone) between the Exchange servers, you can move directory replication traffic off of your primary network and onto the dedicated link. Interoffice e-mail and calendaring functions that only need to go from one server to another can pass through the dedicated route rather than having to go to the outside world.
Of course, you’ll never be able to keep all of the Exchange related traffic off of the primary network. Even if you have a closed e-mail system, Exchange traffic will go through the primary network as it passes from the server to the end user. To reduce this traffic’s impact on the primary network, consider taking steps such as:
- Upgrading from a 10-megabit network to 100 megabits.
- Limiting the number of machines on each network segment.
- Taking steps to reduce replication traffic (more on that later).
Finally, you can reduce MTA-related problems by carefully choosing the location of MTA-related files, such as the MTA queue and the Internet Mail Service Queue. I recommend placing these queues on a dedicated partition with plenty of free disk space. Because Exchange uses these queues so heavily, your best bet is to place the files on a RAID array if possible. RAID arrays offer much faster performance than simply using a single hard disk, and in some implementations, such as RAID 5, they offer a degree of fault tolerance.
Another way that an Exchange Server’s resources can be consumed is through the heavy use of rules. A rule is a condition that’s applied to a mailbox. Typically, rules are used to send automated responses or to filter junk mail. For example, you could set up a rule that moves messages from an annoying user directly to the Deleted Items folder.
The occasional rule here and there isn’t going to have much impact on your server’s performance. Any time a user has an excessive number of rules, however, the processor is forced to spend time comparing every inbound message the user receives to an extensive set of rules.
A general rule is that zero to nine rules per user don’t cause much of a load on the server, but ten or more rules do. If your users have lots of rules set up, you might consider making them client-side rules instead of server-side rules so that the workstations process the rules and the server won’t be bogged down.
Users can establish multiple views in Exchange. A view is nothing more than a way of looking at information. For example, you might create a view that displays your Inbox and calendar. Any time a user creates a view, Exchange Server must use an index to keep track of the view. If used in moderation, views don’t cause much of a problem. That’s because the last few views that a user has accessed are cached. If a user has lots of views defined, however, performance will suffer when switching between views because it’s impossible for Exchange to cache them all. The lesson here is to use views in moderation.
Public folders are yet another Exchange resource hog. If you have a large number of public folders that are frequently used, it’s sometimes a good idea to install a new server with the sole purpose of hosting public folders.
Public folder replication can also have a negative impact on your network. Normally, when public folder replication occurs, only the folders that have changed since the last replication are replicated. In busy environments, however, this can still generate a lot of traffic. The secret in such situations is to control just how often replication occurs. Obviously, the more often replication occurs, the heavier the workload placed on the server, and the more traffic floods your network lines.
By default, public folder replication is set to Always. This setting replicates public folders every 15 minutes. If your organization can get by with less frequent replication, you can really enhance Exchange’s performance by reducing the replication frequency.
One of the best ways of reducing the load on a server is through the use of personal folders. A personal folder is a private storage area that can be used to store messages and other Exchange related items. If you really want to boost Exchange’s performance, create a personal folder for each user on a separate server. Once you’ve done so, you can set Exchange to automatically deliver all messages to the personal folder (which has its own Inbox) rather than to the Inbox. There are several advantages to doing this.
First, it eliminates having s single point of failure. If an Exchange database should become corrupt, it won’t affect anything stored in personal folders. More importantly, though, using personal folders offloads a tremendous amount of the server’s processing burden. To understand why this is the case, consider all of the ways that Exchange has to interact with the private information store database.
On a normally configured Exchange Server, any time a user wants to read a message, Exchange must query the database and read the message from the database. If the messages are stored in a personal folder, however, the server’s database is never touched when a user reads a message because the data is stored locally. Likewise, any time you delete a message, Exchange normally has to move the message from the Inbox to the Deleted Items folder.
Again, if Exchange is configured to work with personal folders, this operation is performed at the local level with no need for server intervention. Finally, any time a user sends a message, Exchange makes a database entry because it saves a copy of the message in the Sent Items folder. Once again, if the client is set up to use personal folders, all of the processing and disk access required for this operation happens at the local level. Once you see just how intensive these basic operations are, you can understand the reason for storing the personal folders on a separate server.
Factors that affect Exchange Server’s performance
Optimizing Exchange Server can be a complicated process. I’ve covered a lot of material in this series. It seems appropriate to take a moment and review the basic techniques that I’ve suggested for optimizing Exchange Server:
- Divide the Exchange Server network into sites whenever Exchange data must pass across a slow WAN link.
- Limit the amount of replication traffic that must pass across WAN links and ensure that the WAN link has adequate bandwidth to service the sites that it connects.
- Use a dedicated partition on a RAID array for your public information store and private information store.
- Use a dedicated partition on a RAID array for your MTA and Internet Mail Service queues.
- Use the fastest CPUs you can on your Exchange Servers.
- Use system boards that are multiprocessor ready and add processors if they will benefit your system.
- Use the largest L2 cache you can get your hands on.
- Be sure that the server has lots of RAM.
- Consider moving the public folders or the connectors to a foreign mail system (such as the Internet) or to a dedicated server.
- Have users’ mail automatically delivered to personal folders that reside on a different server.
- Limit your use of rules and views. If you have to have a lot of rules, process them on the client side instead of on the server.
- Limit the number of times per day that directory replication occurs.
- Limit the number of users on each server, along with their mailbox size and maximum inbound and outbound message sizes.
As you can see, the list of factors that can affect Exchange Server’s performance is quite extensive. In this series, I’ve discussed the most common causes of poor Exchange Server performance. I’ve also shown you how to work around these performance problems. Next month I’ll conclude this series by discussing some methods that you can use to measure how much performance gain you’ve achieved by using my techniques. I’ll also show you how to push your newly optimized Exchange servers to the limit to find out just how much of a load they can handle before performance starts to suffer.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.