Special Edition Microsoft Exchange Server 5.5

Previous chapterNext chapterContents


- 24 -
Exchange Performance Tuning and Capacity Planning



I'm sure every system administrator has had the temptation to launch the network server from the company's roof in order to make it go faster. Likewise, I'm sure you find your temptation increasing when users stop you in the hall to complain about poor performance. However, you can find an alternative to the preceding dramatic option by discovering why Exchange is slow and then taking more positive action to fix the problem.

In particular, this chapter discusses what situations can cause Exchange to operate sluggishly. This is important to know because poor performance costs money in terms of lost time and productivity. The sections in this chapter give you tools to solve your problems. You also learn some answers to that simple question, "How many users can Exchange support?" This chapter also touches on capacity planning, which you need to consider in order to ensure that your server and network can stay ahead of their workload.


NOTE: The examples presented in this chapter might not completely match your environment. It is extremely 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 may have heard before, tuning is more of an art than a science. There are no mystic techniques that detect and tune all Exchange servers in all situations. A majority of the time, you'll find yourself learning how individual system components work together to produce a result. Then you must consider the tradeoff between the different results. For example, you may want to adjust your system components to provide more stability at the cost of slower performance.

Defining Users

Before you can answer the question, "How many users can an Exchange server support?," you need to understand the types of Exchange users in your organization.

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 that seems to cause the traffic to 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, while remote field personnel are satisfied with low-end machines to dial into and receive e-mail.

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

You need 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.

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 users' request. As such, a server's workload rises 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 directory service 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 that this chapter describes.

How Many Users Can Exchange Support?

When a user initiates a request, the server uses one or more of its hardware resources to complete the task. The main resources are the CPU, memory, mass storage (disk drives), and the network card. Suppose a request requires one second of CPU time and two seconds of disk time--and that these cannot overlap. Assume also there is no other process that will interfere with this request's execution. The disk, therefore, is the "bottleneck" of the operation, as it is the resource that expends the most time during a request's execution.

For example, two users issue the same request. Requests arrive at the server spaced three seconds apart. Each request will be serviced, and the users will not notice any unusual delays (other than the typical three-second response time).

However, if the second request arrives one second earlier, a bottleneck momentarily forms as the server is placed under a slightly heavier load and begins to form a queue. Consequently, the second user notices a slightly longer (one-second) delay in response time.

As more users connect and requests begin to queue up, the bottleneck becomes more pronounced. The server will slow down, and there will be some unhappy users.

The point at which server load increases and response time becomes unacceptable is when you've reached the number of users Exchange can support given the hardware.

Three variables exist that affect response time:

As the number of user requests increases, so does response time. The same relationship is true for users per server. Hardware capacity has the opposite relationship: As it increases, so does its capability to handle more users and requests, which results in decreased response time.

The next section shows you how to make your operation more efficient by tuning existing resources and planning for your users' demands.

Using Exchange's Performance Tuning Tools

Three tools exist that can help you tune your server, reduce response time, and make your operation more efficient.


NOTE: For best results, use LoadSim after employing Performance Optimizer and Performance Monitor.

Using the Performance Optimizer

The Performance Optimizer automatically analyzes and optimizes key hardware for the best performance with Exchange.

The Optimizer first analyzes the server's logical drives. Then it determines the most effective location for the MTA, information store, directory, and transaction log files. Specifically, the Optimizer locates the logical drive with the quickest sequential access time and uses it for the transaction log files. It does this because the transaction logs are written sequentially for maximum performance. The Optimizer then locates the logical drive with the fastest random access and uses it for the server's particular role. For example, a dedicated backbone server moving messages to other sites reserves its swiftest random access drive for MTA files. A public folder-only server will use its hard drive for the public information store files.

Keep in mind that the Performance Optimizer can examine a drive down to only the logical, not the physical, level. If you have divided your physical hard drive into sections or if you have partitioned a RAID array into multiple logical drives, the Performance Optimizer cannot provide a drive configuration that will give you increased performance.

The Performance Optimizer also analyzes the total amount of physical RAM and determines the amount of memory needed for the directory and information store. You are also given the option of limiting the amount of RAM that Exchange uses. This is especially useful another application that is running on the server needs a sizable amount of RAM (such as SQL Server).

Although you can and should run the Performance Optimizer immediately after setup, you should consider running it again after you make any of the following changes:

The Optimizer is especially useful in its capability to automatically move the various databases and work queues from one drive location to another while also changing any necessary Windows NT Registry values and Exchange values (for example, if drive space for the Public Folder database (PUB.EDB) becomes constrained and a new multi-gigabyte RAID is added). The Performance Optimizer can be configured to easily shift the PRIV.EDB to the new drive space and make all the necessary changes.

All Microsoft Exchange 5.5 servers should run the Performance Optimizer because the database engine has been significantly changed to better use large amounts of memory and multiple processors.

Using the Performance Monitor

An Exchange system should be structured so its resources are used efficiently and distributed fairly among the users. Performance Monitor (PerfMon) monitors specific system resources so you can meet your system structure goals.

Many times, you might be motivated to solve all problems the instant they appear. In fact, you might find your motivation dramatically increasing when users loudly display their unhappiness. To be prepared for such problems, you should review PerfMon before moving too quickly in one direction. You can do that by using the set of overview counters presented later in this chapter. These counters will keep you from plunging too quickly and deeply into a dilemma, only to discover that you've missed the problem. When your system is under a load you want to monitor, bring up all the overview counters in PerfMon. Then you can determine which resource is being overworked.

PerfMon is powerful enough to be used as a console that runs 24 hours a day and includes thresholds for the various key counters. If a threshold is broken, the monitor might send a net broadcast or spawn a pager process to let an administrator know that attention is needed. This type of scenario helps to proactively solve problems before they affect end users too greatly.

The following sections are presented in order of their influence on Exchange's performance. Within each section, each counter is listed in the format Object: Counter. This will help you locate the particular counter within the Performance Monitor.


NOTE: You might be wondering what a good figure is for Server: Bytes Total/Sec or for MSExchangeMTA: Messages/Sec. The truth is that there is no simple answer because each network has far too many variables.
Next, you might wonder what the maximum values are. Again, there are no simple answers. For example, how could you find how fast your car can go? You can probably discover this by driving as fast as possible. But notice all the variables that will affect your maximum speed. Do you test drive the car up or down a hill, at sea level, or at 10,000 feet? Whether you test drive on a cold or a hot day will affect the result. For example, cold air is denser and provides a performance boost, especially for turbo and supercharged engines.
The best approach is to drive your system through many conditions until you get a feel for its normal ranges or personality. To assist you in this process, LoadSim creates a synthetic load of hundreds of users on your system. While running your simulation, crank up PerfMon to monitor the load.

Detecting Disk Subsystem Bottlenecks

With most Exchange systems, the disk subsystem has the most influence on performance.

The primary consideration with the disk subsystem is not its size but its ability to handle multiple random reads and writes quickly. For example, when Exchange users open their inboxes, the set of properties in the default folder view must be read for approximately the first 20 messages. If the property information is not in the cache, it must be read from the information store on disk. Likewise, a message transferred from one server to another must be written to disk in order for the receiving server to acknowledge its receipt. (This is a safety measure that prevents message loss during power outages.) Now imagine the read and write activity created by 300 heavy e-mail users on one server. Their combined requests would generate a multitude of random traffic on the disk subsystem.


CAUTION: Sometimes, you see extremely high %Disk Times and think that your disk subsystem is causing a bottleneck. However, you want to examine other overview counters before going in any one direction. For example, when available memory drops to critical levels, Windows NT begins to page (write unused data or code to the hard drive to make room for more active programs). In a case of extreme RAM resource starvation, your disk subsystem can be reading and writing furiously and appear to be bottlenecked. Looking at other general disk counters in PerfMon will validate this illusion.
However, when you examine both memory and disk subsystem counters, you'll notice that during prolonged memory paging, disk activity increases. The solution is to add more memory, not to increase your disk subsystem capacity.

If you suspect that the server's disk subsystem is forming a bottleneck that slows down user requests, examine the following Windows NT Performance Monitor counters:

Both counters can monitor either your server's physically installed disk spindles or RAID bundles.

Addressing Disk Subsystem Bottlenecks

Once you have established that the disk subsystem is the bottleneck slowing down your Exchange system, you can implement the following solutions to resolve the problem.

Separating All Transaction Logs

Both the public and private information stores utilize a transaction log that is written sequentially to disk. If possible, place the logs into separate physical spindles, preferably with the private store on the fastest drive, with a dedicated controller on a FAT partition, if possible.

Installing Additional Hard Disks

You can separate Windows NT processes (for example paging file) and Exchange processes (for example message tracking logs) to enhance performance. You can also separate the public and private information stores' transaction logs to separate disks or arrays for even better performance.

Overall, if you have a RAID subsystem, installing more drives coupled with a large RAM cache on the RAID controller yields faster throughput.

Installing Faster Hard Disks and Drive Controllers

Choose a disk with the lowest seek time available (seek time is the time required to move the disk drive's heads from one track of data to another). The ratio of time spent seeking as opposed to time spent transferring data is usually 10 to 1.

Determine what type of transfers the controller card performs: 8-bit, 16-bit, 32-bit, or 64-bit transfers. The more bits in the transfer operation, the faster the controller moves data. Ultra-SCSI technology, available from several vendors, offers an excellent combination of these features. The best way to judge is to run your performance simulations by using the guidelines, counters, and utilities (such as LoadSim) outlined in this chapter. Short of performing a full-scale simulation, your best bet is to find white papers from independent testing firms that profile the latest technology.

Using RAID Disk Striping to Increase Performance

Use RAID 0 (disk striping) to increase overall capacity for random reads and writes. You will need at least two physical drives for RAID 0. Use RAID 5 (disk striping with parity) for slightly less performance but more fault tolerance. You will need at least three physical drives for RAID 5.

If you implement RAID at the hardware level, choose a controller card with a large (4 megabytes) on-board cache. Several vendors offer complete solutions of this type.

Minding Memory Requirements in Exchange

When Exchange runs, it keeps only portions of needed data, referred to as pages, in memory at any one time. When it needs a page of data that is not in RAM (page fault), Windows NT loads that page into physical memory from a peripheral device, which is usually the hard drive. The average instruction in memory executes in nanoseconds, which is one-billionth of a second, and hard drive seek and access times are in milliseconds. Therefore, Windows NT must run 100,000 times slower than normal to retrieve a page from disk.

Keep in mind that Exchange needs a minimum of 32MB of RAM, and experience has shown that 64MB is a much more realistic level, given all that a Windows NT server and Exchange need to do quickly in RAM.

Detecting Memory Bottlenecks

The best indicator of a memory bottleneck on Exchange Servers is the rate of hard page faults. Hard page faults occur when the application cannot find data that it needs in memory and must access the disk subsystem to retrieve it. This slows down the Exchange Server because the data must be taken from the disk subsystem, a process that is slower than retrieving the data from memory. Accessing the data from the disk subsystem also increases the load on the disk subsystem.

This is why adding more memory to the Exchange Server can solve some disk subsystem bottlenecks that affect performance. Examine the following Windows NT Performance Monitor counter to determine if the Exchange Server's memory is forming a bottleneck:

Addressing Memory Bottlenecks

If you determine that the memory on the Exchange Server is forming a bottleneck, you can implement the following solutions to resolve the situation.

Adding Memory

You will want to add more memory until paging stops or occurs minimally. Afterward, be sure to run Performance Optimizer to adjust Exchange's memory caches.

Using Multiple Paging Files

If your disk subsystem supports concurrent I/O requests, using multiple paging files usually improves system performance. Be sure to place the paging file on your fastest hard drive, and then experiment with separating Windows NT's paging file from Exchange's transaction log files.

Removing Unnecessary Services

Disable any unneeded Windows NT services, protocols, and device drivers. Even idle components consume some memory and contribute to general system overhead.

The next section discusses performance issues related to your network infrastructure.

Detecting Network Bottlenecks

A network, by its heterogeneous nature, is full of potential performance bottlenecks. A company full of servers and clients talking in different protocols can often cause poor performance from Exchange. The following sections offer guidelines for detecting poor network performance with Exchange and suggestions to help you improve it.

When a network bottleneck forms, one of the following three scenarios can result:

Detecting Client Side Bottlenecks

The following counters are available to clients running Windows NT:

NWLink: Bytes Total/Sec (IPX/SPX)

Network Interface: Bytes Total/Sec (TCP/IP)

NetBEUI: Bytes Total/Sec

If you want to measure a client's workload, use the appropriate counter for your protocol. When your overview counters are generally idle but your network counters are high, you can usually infer that your network has a bottleneck on the client end. This means that your client is doing most of its work gabbing with the network.

In addition to the counters listed previously, the following counter also gives you an indication of how much load a particular client is placing on the network:

Detecting Server Side Bottlenecks

The following counters detect server side bottlenecks:

The following sections include suggestions that will improve network performance among your Exchange servers.

Addressing Network Bottlenecks

Once you have identified that the network is forming a bottleneck that's slowing down Exchange client-to-server response times, you can implement the following solutions to resolve the problem.

Applying Faster Hardware on Heavy Traffic Links

For the most leverage, you should apply hardware upgrades to machines generating the most traffic, as well as servers on the heaviest traffic links. This will provide a system-wide balance for your Exchange environment.

You can use a combination of the counters mentioned in the previous sections to determine which machine is generating traffic. A product such as Network Monitor (included as a tool with Microsoft SMS) or a standard network sniffer can determine which network links experience the greatest load.

Segmenting Your Network

If the Server: Bytes Total/Sec or corresponding client counter begins to reach the maximum bandwidth of the network link to which your server is connected, you should consider segmenting your network. On an ethernet segment, this value is approximately 1.2 megabits per second, including the overhead of the network.

Matching the Network Card to the System Bus

If your client or server has a 32-bit or 64-bit bus, use a 32-bit or 64-bit adapter card. Overall, you should use the fastest network card and matching bus available. Bus Master devices offer the best solution because they have their own intelligence and offload processing from the CPU.

Increasing Your Bandwidth

If you determine that your network is overloaded, increase its bandwidth by upgrading to faster network link technology, such as Fast Ethernet, FDDI, or ATM.

Detecting Processor Bottlenecks

Exchange is tightly integrated with Windows NT. Therefore, it can take full advantage of a more advanced processor or multiple processors. You should eliminate all other possible bottlenecks before investigating the processor. You can detect a processor bottleneck by monitoring the following counters:

If the % Processor Time exceeds 90% consistently on single processor systems or if it exceeds 50% on multiprocessor systems, the processor is possibly a bottleneck. Furthermore, if the Processor Queue Length often exceeds 2, the processor could be a bottleneck. However, this is not always true. Other devices on the server, such as memory, could form a bottleneck, which in turn increases the amount of processor use.

Addressing Processor Bottlenecks

Once you identify that the processor is truly the bottleneck affecting performance on your Exchange Server, you can implement one of the following solutions to resolve the problem.

Upgrading Your Processor

You can upgrade to the fastest processor available. Having done that, you can add additional processors if your hardware supports symmetrical multiprocessing. Keep in mind that Windows NT supports Power PC and Alpha as well as Intel processors.

Overall, adding another CPU typically gives a better performance increase than upgrading to a faster single processor does. The reason is that the multithreaded design of all Microsoft BackOffice products enables superior performance in a multiple processor environment.

For example, a server with two 90MHz CPUs outperforms a server with a single 200MHz CPU because Windows NT's symmetric multiprocessor (SMP) functions allow many more threads to be active.

Using Off-Peak Scheduling for the Processor

You might also consider scheduling processor-intensive activities during off-peak hours. Such processor-intensive functions might include generating the Offline Address Book, updating the routing table, or creating and sending storage limit warnings to users.

Detecting System Bus Bottlenecks

If you have a Pentium or Pentium Pro system, use the p5ctrs from the Windows NT Resource Kit to detect any bus bottlenecks. You'll have to take an extra step of running pperf to configure which of these Pentium counters you want to see:

Pentium: Bus Utilization (clks/sec)

Pentium: % Code Cache misses

Pentium: % Data Cache misses


CAUTION: Keep in mind that any counter or utility from the Windows NT Resource Kit has not been regression tested by Microsoft and is explicitly not supported by any area of Microsoft (including through the Web and Microsoft-monitored newsgroups). It is strongly recommended you test in an isolated lab environment before releasing into production.

If you see high bus utilization for your system and a high percentage of code and data cache misses, your bus may be forming a bottleneck.

Addressing System Bus Bottlenecks

Having identified the system bus as the bottleneck, you can implement the following solutions to resolve the problem.

Using Larger CPU Caches

If there are a lot of cache misses, upgrade to the next largest or the largest L2 cache available.

Using Off-Peak Scheduling for the Processor

As for processor bottlenecks, you might consider scheduling processor-intensive activities during off-peak hours. Such processor-intensive functions might include generating the Offline Address Book, updating the routing table, or creating and sending storage limit warnings to users.

Also, investigate and relocate any non-Exchange services that can be executed on a separate machine.

Exchange-Specific Counters


NOTE: The following Exchange counters are available in PerfMon after you have installed Exchange.

The counters described in this section provide Exchange-specific monitoring information. If you are just beginning with Exchange or are new to monitoring, stick to the preceding hardware-specific counters. They provide an accurate high-level view. When you are ready to drill down on specific Exchange components, however, use the counters outlined here for detailed bottleneck detection.

Trend Counters

For best results, track trend counters with Performance Monitor's log. This allows you to average out the day-to-day spikes that can lead you down the wrong road. This average also sets a baseline of typical loads for your server.

Of course, you're also welcome to view these counters for an immediate snapshot of your server, but bear in mind that the numbers will be fairly meaningless unless you have a baseline to measure against. You should use the following Windows NT Performance Monitor counters when analyzing the usage trend on Exchange servers:

Service Time Counters

For best results, you should also track these counters with Performance Monitor's log. However, these counters are better suited for on-the-spot monitoring and evaluation, especially those counters that should be zero for the best throughput.

The following are service time counters. They tell you if the components are keeping up with the submitted load. The queues may be non-zero at peak traffic times, but they shouldn't stay there consistently, especially during slow times.

The following counters indicate how long it takes the store to deliver messages:

Optimizing Dedicated Exchange Servers

This section is for advanced Exchange administrators who want to divide Exchange's functionality onto separate servers for even better performance and improved redundancy. Each server's hardware will be used differently depending on the dedicated role it's fulfilling for Exchange. After determining which hardware resource will be in demand, use the monitoring information and recommendations mentioned earlier to optimize the server for its role.

Optimizing Messaging Servers

Exchange servers that just facilitate user requests spend most of their time accessing the information store (IS) log and database. Because these two components have different personalities, you should create a disk environment that is tailored for maximum throughput for the appropriate IS need.

The IS log is stored on the hard drive, so use the fastest hard drive possible. Because the log is written sequentially, consider isolating it on a dedicated drive or even a dedicated cached controller and drive.

The IS database should also be on the fastest hard drive possible. Choose one with the lowest possible seek time because the database is accessed randomly. For best results, combine drives with low seek times in a RAID-5 array. Typically, the controller will have an on-board cache. The striping should speed up things considerably.

Besides the disk, the next most common bottleneck on dedicated user servers is the CPU. Use the processor counters and recommendations outlined earlier in this chapter to detect and eliminate any such bottlenecks.

The next most important things to monitor are network and memory resources. Again, use the counters and recommendations provided earlier.

Optimizing Connector Servers

A dedicated connector server uses one of Exchange's connectors (X.400, cc:Mail, IMS, site, or cc:Mail) to interface with other messaging platforms. Typically, the server will also serve non-Exchange clients using POP3, HTTP, NNTP and so on.

The key Exchange component in action is the MTA. Like the IS database, it uses the hard drive in a non-sequential (random) manner. You can use the IS database recommendation for disk bottlenecks on a connector server.

The next resource to monitor is the network interface. Review the network bottleneck section in this chapter. If any WAN links are involved, review Chapter 5, paying particular attention to the network links section to ensure that your WAN is adequate.

Finally, you'll want to look at the CPU. Connector servers can perform an extraordinary amount of message translation when talking to non-Exchange messaging systems. This translation tends to be CPU-intensive at times, so examine your processor counters and take the most appropriate action.

Optimizing Public Folder Servers

You'll have a more difficult time discovering the cause of bottlenecks on dedicated public folder servers. Because a public folder is so versatile, its usage and resulting load on hardware resources varies across a wide spectrum. For example, one company may use the folders to distribute a department status each week even though there isn't any posting of replies back into the folder. This kind of use is much different from a company that pulls and pushes gigabytes of newsgroups using Exchange's NNTP functionality.

The best approach here is to use the general purpose PerfMon counters to get an overview for your particular company. You may want to track these counters over time to ensure that your on-the-spot checks aren't missing the big picture. When you have discovered the hardware resource that's consistently bottlenecked on average, you can step in to alleviate things.

Typically, if your company is a heavy public folder user, you'll want to consider splitting the IS public database and logs to separate disks. Specifically, if it does more reading from the folders than writing, tune your disk subsystem for the IS database (non-sequential disk access). For heavy writing, focus on the IS logs (sequential disk access). Typically, companies with a strong appetite for using NNTP for Internet newsgroups will fall into the latter category.


CAUTION: Because each client must obtain the public folder hierarchy from a public information store, you need to take care when creating a dedicated public folder server. If you dedicate public folder servers, the server will reply to clients, which requires the public folder hierarchy and public folder contents. This creates load on the public folder servers and network. Maintaining a public folder store on private servers enables the client to retrieve the hierarchical tree information from his or her local server. This increases performance because the requests for the public folder hierarchy are distributed to multiple servers.

Optimizing Servers with Shared Roles

In smaller shops, Exchange often shares the server's resources with other non-Exchange functions (logon validation, SQL, print serving). If dedicating Exchange isn't an option, use the set of PerfMon overview counters to profile your particular system and determine how your particular mix is affecting the server. If you're planning to deploy Exchange to a server with other responsibilities (for example, a Primary Domain Controller), take the time to use LoadSim to determine if the server's current hardware will handle the additional load from Exchange.

Real World Answers to "How Many Users Can Exchange Support?"

Microsoft has provided a tool called LoadSim that applies the load of users against an Exchange Server. This tool is extremely valuable when trying to determine how many users a server can support or where a bottleneck resides. LoadSim is configurable to match the type of users in your organization, which means you can validate the Exchange hardware prior to it being used in production.

LoadSim can help you measure response times by using an artificially generated server load. LoadSim can also measure "user acceptability" by weighting certain actions that are perceived as more important by the user (for example, weighing opening versus sending). Most users expect mail to open quickly, but are comfortable with a slight delay when sending.

Calculating Acceptable Server Response Times

LoadSim measures two items with respect to an Exchange server: response time and "acceptability." To measure response time, LoadSim uses the 95[th] percentile. If the 95[th] percentile for a set of actions is one second, 95 percent of the response times are at or below one second. Only five percent (one in twenty) of the response times exceeded one second. To compare, the maximum response time is the 100[th] percentile (in other words, 100 percent of the response times are at or below the maximum).

To measure acceptability, LoadSim places a heavier weight on simulated actions that are perceived as more important to a real user. For example, most users expect quick responses when opening or deleting messages. They aren't, however, as affected by a small delay when sending mail. The actual actions and weights are categorized in Table 24.1.

Table 24.1  LoadSim's Weighted Values

Action Weight
Read 10
Delete 2
Send 1
Reply 1
Reply All 1
Forward 1
Move 1


NOTE: LsLog is a LoadSim tool that enables you to change the default percentile (95) and the weighted values for any actions. For more information, refer to the LoadSim documentation and online help.

To arrive at the final number, LoadSim multiplies each percentile value by the corresponding weight. Then LoadSim adds the results and divides by the sum of all weights. This final number is referred to as the score; it represents the response time experienced by a simulated user.

The following list includes client requirements and recommendations that might make your LoadSim experience more productive:

LoadSim isn't a perfect simulation of your environment. Its numbers are only good estimates. Despite this, you will still find LoadSim's data extremely useful.

Capacity Planning with LoadSim

At the time of this writing, the author team for this book had the most current code base of Exchange 5.5 (RC1). Unfortunately, it had not been fully optimized for accurate testing. Thus any LoadSim scores would be extremely distorted and would not reflect real-world findings.

When Microsoft releases a fully optimized beta version or the final version, an errata will be posted on the Que Web site with the test statistics and a graph illustrating simulated users and their response times. You can find this and other updates at www.mcp.com.


Previous chapterNext chapterContents