This section discusses roles a server might fill in your messaging topology. For each role, general recommendations have been made. These recommendations are based on the assumption that you want to deploy a server with the highest possible capacity. If you don't need to "max out" the server, you may not need to follow some of these recommendations.
The following areas are discussed to help you improve performance on servers that are primarily supporting users.
In the most common customer configurations, the disk subsystem and memory are the first resources to become saturated in a Microsoft Exchange Server computer. One significant thing you can do to improve disk performance is to get the information store log files on to their own physical disks, apart from other files in the system. Because the logs are always sequentially written, having dedicated disks means that the disk heads won't be randomized by other activities. They will always be in the right place for the next write. And because seeking is the slowest thing a disk does, this is a big help.
The information store database files, on the other hand, are randomly accessed. In this case, the best thing you can do is to put the disks in a RAID array for maximum random access performance.
You can improve performance by using good disk controllers. Caching controllers increases your disk's performance for reading, and if the controller has battery backups, this can improve write performance as well. If the controller works as a write cache (or caches writes) then it must be battery backed up. Problems with cache writes (for example, in the event of a power outage) will cause the computer to lose data. Batteries are on the card to keep data on the card backed up. If the data is cached and there is a power outage, the data will be saved, not lost. Make sure that you don't put so many disks on one controller that the controller becomes a bottleneck.
It is important to consider the reliability of these disks, because your users will be depending on them. It may be wise to mirror the log files, and to use RAID 5 on the database.
Recommendations
After disks and memory, the next most likely resource to become saturated is the CPU.
Use the fastest possible CPUs. If the server supports only users and does not run connectors and other processes, there are limits to how much work you can offload by adding CPUs. If the server performs other processing functions, there is a definite benefit to adding more processors. For example, it may be useful to add processors if your server supports connectors or doubles as a messaging hub, domain controller, or SQL Server database.
To make the best use of your processors, use a large L2 cache. This keeps the processor from waiting while data is retrieved from main memory. Also, in a multiprocessor server, the cache keeps load off the system bus, which improves your overall throughput.
Recommendations
Two other resources that can be saturated are memory and network capacity. If the system is thrashing (that is, if there is excessive paging), it will be obvious. If it's not thrashing, you will not notice paging at all. Not enough memory in the system will cause the system to thrash. Fortunately, it is easy to add memory to correct this.
If there is not enough network capacity (bandwidth) between the users and the server, your efforts to provide a responsive server will be unsuccessful. The network will be your bottleneck.
When local area network (LAN) connectivity is used, you have the option to replace a 10 MB Ethernet with 100 MB.
In a wide area network (WAN) scenario, there are two important things to note. First, this type of traffic is very bursty (characterized by large bursts of activity). It is not unusual to see peak usage several times the average. Second, bandwidth demand varies widely from company to company and site to site. You may see wide range characteristics of per usage bandwith utilization, depending on the usage patterns. It is typical for server-to-client traffic to be three to four times the client-to-server traffic, because the server responses to client requests are bigger than the requests themselves.
Recommendations
The following tasks create additional work for a server:
The message transfer agent (MTA), for example, will be involved when connectors are used. The MTA secures all messages to disk, so if there is a lot of traffic, disk input and output can become important. One option is to provide a separate disk for MTA files; another is to maintain the MTA files in the stripe set with the information store database. The same is true for the Internet Mail Service because it also secures messages to disk.
Make sure that you have adequate network bandwidth to carry the traffic. Connector traffic will often be carried over WAN links, and as mentioned earlier, the traffic patterns can vary widely from company to company. Use the Network Monitor to verify that you have capacity available on the links.
Most connectors require the system to send and receive messages in a format that is different from the storage format. Mapping content from the storage format into another format or protocol is a CPU-intensive task that may benefit from more processors.
Recommendations
The usage patterns for public folders vary from company to company. Some don't use public folders, others support discussion groups and news in public folders, and others deploy intensive workflow applications. If your organization supports large-scale public folder activity, keep in mind that the public information store is a separate database from the private information store. It has its own database file. This means that you can maintain the public information store database files on a logical drive that is separate from the private information database, for maximum random I/O performance. Likewise, you can maintain the public store database on a separate drive, although this is less likely to increase performance if you already have a stripe set for the database. The 16 GB limit on the private and public stores are separate, so the public store space isn't counted against the 16 GB limit of the private store, and vice versa.
Many site administrators may want to provide Internet newsgroups or Usenet, and store this data in public folders for uniform user access. In such a case, the incoming news may generate a large amount of write activity in the public store, so be sure to optimize the log drives.
Although the public and private stores are separate databases, a single instance of the database engine runs both. They share the same memory buffers. If your organization experiences heavy use of public folders, you can improve performance by splitting the public folders onto separate servers. This reduces contention for computer resources, including buffers. A pool of public folder servers can also provide flexibility in load balancing.
Recommendations
If your organization supports Microsoft Exchange Server in combination with other applications such as SQL Server, or if you use file and print services or domain controllers, you must benchmark the workload and configuration you expect to run. This is the only reliable way to determine the system performance under the expected load. Load Simulator is available to emulate the Microsoft Exchange Server part of the workload.