Understanding Exchange Performance
Tuning a system for optimum performance is an iterative process. You must analyze, test, and adjust your system as many times as needed, and this iterative process includes Microsoft® Exchange Server 2003. You must take the time to understand all the variables that affect your system, including user profile, architecture, and hardware.
Generally, the performance of a server is determined by the component that has the lowest performance—the bottleneck in the system. The key to improving performance is being able to identify bottlenecks, determine their cause, and apply the appropriate corrective action. As you plan your Exchange Server 2003 deployment, use this guide to help design and optimize your environment. Later topics provide metrics and tuning tips to help you reach optimum performance from your Exchange server.
The concept of performance is closely related to the concept of scalability. When you have a solid understanding of the factors influencing the performance of system components, you can deploy components in a way that scales to support periods of high demand. Later topics in this guide cover scaling front-end and back-end servers and provide detailed metrics about how Exchange Server 2003 scales under different conditions.
Note
For Exchange 2000 Server users, many of the concepts are the same. Later topics discuss the differences between the two versions. Exchange Server 5.5 users should review this guide along with the other guides that are recommended in the Introduction.
Measuring Performance
Several tools for measuring performance are included with Exchange Server 2003, including Exchange Server Stress and Performance (ESP) 2003, Jetstress, and Load Simulator 2003 (LoadSim). Microsoft Windows Server™ 2003 also includes some general performance tools including Network Monitor and System Monitor. For more information about tools, see Appendix A, "Exchange Server 2003 Performance Tools."
In addition to these tools, analyze your current user loads to establish a minimum server requirements baseline. Understanding how your users use the system is one of your biggest challenges. Later topics in this guide provide a method on how to measure specific CPU, memory, and storage loads in relation to your current user loads. After you determine your hardware requirements, you should conduct a pilot test to make sure performance levels are acceptable. For more information about pilot testing, see "Laboratory Testing and Pilot Deployments" in the "System-Level Fault Tolerant Measures" topic in the Exchange Server 2003 High Availability Guide.
Hardware Performance
The hardware that you select for your Exchange deployment has the greatest effect on performance. Because of the large number of variables that affect performance, it is difficult to predict the effects on performance of any particular hardware component. The following sections provide general information about what components affect Exchange Server 2003 performance, including processors, memory, network, and storage.
Processor Performance
The processor usage on a server should maintain a load of about 60 percent during peak working hours. This percentage level allows room for periods of extreme load. If the processor usage is consistently greater than 75 percent, processor performance is considered a bottleneck.
There are several factors by which the CPU in a server affects performance. These include:
The processor clock speed, measured in megahertz (MHz) or gigahertz (GHz).
The number of processors.
The type of processor.
For performance, selecting the fastest processor yields the best results. However, budget cost dictates most companies' choices.
Besides the clock speed, the technology used in a processor can affect performance. For example, some processors use Hyper-Threading Technology, which enables a single processor to act as two virtual processors. Such processors typically incorporate advanced cache management and increased bus speed features.
Exchange can fully use multiple processors and, in many cases, using servers with more processors improves performance. However, the relationship between the number of processors and performance is complex. If the server has too many processors, the overhead associated with context switching can be greater than the benefit from the additional processors. The optimum number of processors is partly determined by the role that a server plays. For example, a back-end mailbox server hosting many MAPI connections may make efficient use of an eight-processor computer. By contrast, a server used to host Microsoft Outlook® Web Access users makes better use of a four-processor computer.
For information about how different processors perform, see Scaling Exchange Server 2003.
Memory Performance
Exchange services typically consume no more than 3 gigabytes (GB) of physical memory. After you add operating system requirements and antivirus, backup, and management software, the total physical memory that is used can approach 4 GB. On servers that are dedicated to Exchange, you do not need more than 4 GB of memory.
The biggest individual consumer of memory in Exchange Server 2003 is the Store.exe process, which manages mailboxes and public information storage
Besides the Store.exe process, other processes that consume memory (and may affect performance) include:
Inetinfo.exe Process that handles Internet protocols
Emsmta.exe Microsoft Exchange MTA Stacks service
Mad.exe Microsoft Exchange System Attendant
For more information about memory optimization, see Tuning Exchange Server 2003 Performance.
Network Performance
Much of the network interface subsystem is tuned automatically. Server-based network adapters are capable of detecting the type and level of traffic passing through the network interface, and they self-tune to reflect this information. Beyond making sure that you have the latest device driver on the server, there is not much to do here.
For mailbox servers, a full duplex 100 megabits per second (Mbps) network connection is typically sufficient. However, if you plan to back up and restore across the network, consider using gigabit Ethernet (1,000 Mbps or 1 gigabits per second [Gbps]).
Generally, the greatest bottleneck in a front-end and back-end server configuration is the network that separates the two sets of servers. Front-end servers can consume a 100 Mbps LAN connection. Therefore, consider multiple switched fast Ethernet networks of gigabit Ethernet connections.
Performance-related issues may be because your hardware, firmware, or software drivers are not designed to work in your configuration. For more information, see the Products Designed for Microsoft Windows Web site.
Storage Performance
As storage requirements increase and companies consolidate servers, you must balance the cost, availability, and performance when you design a storage system. Take time to invest in good storage design before you implement it; unlike processors and memory, which you can scale while the network is active, storage redesign requires network downtime to implement. Tuning your Exchange storage becomes the most critical component.
There are many storage solutions available, including locally attached storage and storage area networks (SANs). The storage requirement of an Exchange server depends on the role of the server. For example, a back-end server would benefit from a SAN because of the large amount of critical data the server must store and present. SANs are specialized storage hardware that incorporates redundant array of inexpensive disks (RAID) technology to ensure high availability and performance. In contrast, a front-end server is more processor intensive, and it does not require an advanced storage solution.
With the advancements in data capacity, adding a larger capacity hard disk drive does not solve performance issues related to increased user loads. You must consider the ability of each hard disk drive to respond sufficiently to various user loads. This ability can be measured by analyzing your current user loads. Chapter 2 discusses a method you can use to analyze your current database usage. With this data, you can estimate your storage requirements.
For more information about storage strategy, see the Exchange Server 2003 High Availability Guide.
General Architecture Considerations
Whether you deploy a small (single server) or large (multiple front-end and back-end servers) scale environments, you must consider challenges that affect your overall performance.
A front-end server is a server that receives requests from clients and relays them to the appropriate back-end server. A back-end server is a server that hosts at least one database to which front-end servers connect when relaying requests from clients.
Regardless of architecture, many factors affect the performance of an Exchange server. These factors include the protocols being used, number of installed processors, available memory, network traffic anticipated, use of secure authentication, and use of Secure Sockets Layer (SSL) to encrypt network traffic. You must take such factors into account before you select your hardware for a specific Exchange Server 2003 configuration.
For more information about front-end and back-end server performance, see Scaling Exchange Server 2003.
Troubleshooting Performance
With the troubleshooting tools listed in Appendix A, you can start to diagnose where Exchange Server 2003 performance has decreased. Poor server performance is frequently a result of an underperforming subsystem. For an Exchange server, performance degradation has the symptoms of increasing mail queues or poor client response.
For more information about troubleshooting performance, see Troubleshooting Exchange Server 2003 Performance.
Summary
Understanding the different factors that affect Exchange performance is the first step in achieving optimum performance. You must continue to test, analyze, and adjust your system. Additionally, understanding your current user loads can help you determine what your scaling requirements are. With this information, you can better predict what your hardware requirements will be. The following topics provide specific examples and techniques for determining hardware needs and tuning specific components.