Home > Articles

Tuning Exchange 2000

  • Print
  • + Share This
Former Microsoft employee and three-time Exchange author Kent Joshi discusses the basic approaches to tuning Exchange Server's most common performance issues.
From the author of

In this article, we will cover:

  • The art of performance tuning

  • How many users Exchange can support

  • What's in the Tuning toolbox

  • Detecting disk subsystem bottlenecks

  • Addressing disk subsystem bottlenecks

  • Detecting memory bottlenecks

  • Addressing memory bottlenecks

  • This set of topics will allow you to understand the fundamentals of how to secure your messaging system against various threats using Exchange and Windows 2000's set of toolkits.

    The examples presented in this article might not completely match your environment. It is important that you recognize your environment's unique elements and move forward with the most appropriate tuning strategy.

    The Art of Performance Tuning

    As you might have heard before, tuning is more of an art than a science. There are no magical properties or techniques to help you detect and tune all Exchange servers in all situations. Most of the time, you'll find yourself learning how individual system components work together to produce a result. Then you must consider the trade-off between the different results. For example, you might want to adjust your system components to provide more stability at the cost of slower performance.

    Before we discuss the how to solve your tuning problems, let's define the key elements of the problem itself.

    Defining Users

    Understanding the types of Exchange users in your organization is critical to tuning success.

    Usage patterns show that users read and generate anywhere from a few messages each week to hundreds of messages every day. A small percentage of the user population, therefore, can be responsible for a majority of usage. It's a bit like driving in the left lane on the highway and encountering some traffic: There's always one slowpoke who makes the traffic slow down.

    Overall, you must understand the different types of users (light, medium, or heavy) within your organization, as well as their daily tasks.

    Defining Servers

    Obviously, each organization will purchase hardware specifically for its business needs. Take, for example, a centralized company with one main location and several warehouses and sales offices distributed throughout the country. The firm might house most of its computing power in corporate headquarters in the form of high-end servers. The company then places cheaper low-end machines in the remote offices. The high-end servers meet the needs of power users in headquarters, whereas remote field personnel are satisfied with low-end machines to dial into and receive email.

    In another situation, a company might have several independent business units throughout the country. In this firm, midrange servers are used to provide computing power as close to the customer as possible. Therefore, each business unit can provide the fastest service.

    It is important to understand your company's use of server resources, as well as distinguish between low- and high-end machines (CPU speed and RAM) as defined by your organization.

    Defining Load

    When monitoring a server, you will notice its workload rising as more users connect and begin to work on it. In addition, you might notice other remote servers connecting to the server (through Exchange's connectors), thereby generating even more load. The remote servers have users connecting and asking their local servers to perform remote tasks. These remote user requests ultimately are generating some load on your local server.

    All server load, therefore, is ultimately generated by users' requests.

    Defining Direct Versus Background Requests

    When a user asks the server to open an unread message, the server performs that task as a direct result of the user's request. As such, a server's workload rises almost in direct proportion to the number of users working directly with it. On an Exchange server that is serving only users, direct requests such as these make up most of the load. Direct requests are also synchronous in nature.

    Background requests occur when a server is performing a task related to or on behalf of a user's request. Some examples of these tasks include replicating public folders and Active Directory information, expanding distribution lists, performing background maintenance, and transferring and delivering mail messages. As with direct requests, the load resulting from background requests is also proportional to the number of users directly connected. However, background requests occur asynchronously. Therefore, users do not need to be directly connected to initiate this work.

    In the context of background requests, delivering mail places most of the load on the server. The resources consumed for message delivery are directly proportional to the volume of mail generated by your users. Therefore, accurately determining what types of "users" are within your organization is key to tuning Exchange.

    Remember, direct and background requests create different types of load on the server. You can measure this with the tools described in this article.

  • + Share This
  • 🔖 Save To Your Account