Previous Page TOC Next Page



— 6 —
System Requirements for Optimal Performance


by Greg Todd

This entire section of the book pertains to the planning process for rolling out Microsoft Exchange Server. In addition, the process is given good coverage in the Installation Guide and the Concepts and Planning Guide, which are part of the Exchange Server documentation. You should definitely refer to those manuals for more suggestions regarding the planning process. As I point out in other chapters, this book is intended to complement rather than replace the documentation. Perhaps, after reading this, you will have even more insight into what it takes to plan a rollout of Exchange Server.

The planning process is a multifaceted exercise that can sometimes take a while to complete. It generally consists of topics such as understanding the Exchange Server software, determining exactly what you want Exchange to do for you, anticipating the security aspects, planning how both Windows NT Server and Exchange Server will fit with your enterprise's structure, setting expectations for performance, determining what hardware to use—the list goes on.

For some people, the thought of planning alone is enough to cause pain. For others who are less planning averse, the idea brings happy thoughts of an orderly structured world where things actually go according to plan. Whatever your personal response, one of the most important parts of the planning process is to get an accurate understanding of the system requirements for your Exchange server. This includes both setting an expectation of how the system should perform and deciding exactly what hardware to choose for your server. And because planning certainly is an important part of a successful Exchange rollout—especially in larger, more complex scenarios—you should spend some time doing it.

Bear in mind that it is impossible to tell you exactly which hardware you need for your specific environment. Even if I tried, it would probably be wrong. However, what I can do is provide guidelines and concepts you can use to fit your situation. This chapter offers information that will help you make an informed decision about your own system requirements. Along with that, it discusses a couple of tools that will help you refine your requirements and give you hard data to back it up—or to justify changes. These tools come with Microsoft Exchange Server right out of the box, so there's no need to go tool hunting or to buy anything else.

The following are the topics you'll look at in the context of system requirements:

First, this chapter handles the question to which everyone wants an answer: how many users will Microsoft Exchange Server support? Unfortunately, there is not a straightforward answer to this question. However, this chapter will give you some insight into the issues surrounding the question so that you can answer it for your specific installation. After all, that's the one you care the most about.

Next, you learn concepts related to planning the components in the main subsystems of your server: CPU, disk, and RAM. These are the most crucial components to Microsoft Exchange Server, and they deserve the most attention.

After that, you will get an advanced peek at the Microsoft Exchange Optimizer. This utility plays an important role in getting Microsoft Exchange Server parameters configured properly on the hardware you've selected. You'll get a feel for some of the questions it will ask you and for some of the parameters it configures—before you start the Exchange Server setup process.

Finally, the chapter wraps up with a discussion of two tools helpful to understanding Exchange Server performance: Microsoft Exchange Server objects and counters found in Microsoft NT Performance Monitor, and Microsoft's client-load simulator utility, LoadSim. These are useful tools in helping you understand your own system requirements. Because determining precise hardware requirements can be an ongoing thing, with these you should be able to refine your requirements over time.

After you read this chapter, you should understand general implications of performance on your Microsoft Exchange Server hardware requirements. Also, you will have a jump on things because you will have general ideas about how to set up Exchange for good performance before the installation process begins. Finally, you will know how to apply Performance Monitor and LoadSim to the task of understanding Exchange performance.

You might be familiar with some of the topics I plan to cover here, or you might never have thought about them. Regardless, it's worth your while to take a few minutes and read through this chapter. And when your boss wonders how you knew so much about this stuff, you can just smile. So grab a chair and some refreshments and read on.

Number of Users Per Server


If you think about it, the number of users per server—or server capacity—is one of the key issues driving the entire system-requirements process. The first question out of people's mouths is usually, "How many users can Exchange Server support?" More to the point, the number of users you need to support is a main issue when deciding how much hardware to throw at Exchange Server.

There's good news and bad news. The good news: This is the question everyone else is asking, so you're asking a valid question. The bad news: There is no simple answer to the question. The answer depends upon what the users will be doing with Exchange. Put simply, the usage profile of your users has a direct impact on how many users your Exchange server will support for a given hardware configuration. Of course there are other factors that influence server capacity, but the main factor is user profile.

Say your users are pretty new to e-mail. They have never really tried the brave new frontier of electronic communication via computer, so they are going to get their chance by using Microsoft Exchange Server. Chances are good this type of user will have light usage patterns and consequently won't place much load on the system. A single Exchange server can handle many users with this type of usage profile; a thousand would be no problem.



Incidentally, when you look at LoadSim later in this chapter you learn about using it to simulate users with a certain usage profile. LoadSim has three default user profiles—Low, Medium, and Heavy—which are good for modeling performance for different classes of users.

On the other hand, maybe you have more sophisticated users who have significantly higher expectations of their e-mail system. In contrast to e-mail neophytes, their usage patterns are quite heavy; these are advanced users who send and receive lots of e-mail. They require connectivity to many other e-mail users, quite possibly all over the world. In short, e-mail is a basic part of daily life. As a result, these users will demand more of their server and will place a higher load on Exchange. In this case you will be able to support fewer users on the same hardware platform—maybe half, give or take some.

Make sense so far?

Now, a single Exchange server can handle varying numbers of users, from very small installations of say, 25, up to huge installations in the thousands. Naturally, this user scaling depends on the hardware and the user load. With modest hardware, such as a 486/66 with 32MB RAM and a single disk, you can expect to handle 100 or less light (or "Low," in LoadSim terminology) users who are only using e-mail. At the other end of the spectrum, say, with four Pentium/166 processors, 512MB RAM, and a couple of huge hardware-disk arrays, you can realistically expect to approach 2,000 simultaneous light users (probably more, depending on the exact user profile and how the hardware is configured).



In this context, when I'm talking about numbers of users I am referring to simultaneous active users, not total users on the system. Don't confuse this with how many users have accounts or mailboxes on the Exchange Server machine. For example, there can be 2,000 user mailboxes residing in the Exchange server directory, but if there are only 200 users active at any one time, plan the hardware around the 200 active users.

Of course, one other important factor to consider is what is acceptable in terms of response time. How fast do your users require the system to respond? Generally, the rule of thumb is to keep response times at a second or less. If you can live with slower response times, you can support more users on a given hardware configuration. For example, some folks use three seconds as the maximum response time, so they should be able to support more users on the same hardware configuration than those who require one-second response time. Regardless, the response time requirement has a definite impact on the planning process.

Arguably, the most common range for Exchange server installations is 200-500 concurrent users per server. This can be supported by a single Pentium/133, 128MB RAM, and two fast disk volumes. You learn the details of this implementation later in this chapter in the sections about configuring the server, "Choosing the Right Processor," "Choosing the Right Disk Subsystem," and "Choosing the Right Amount of RAM."

To summarize, Table 6.1 provides some basic guidelines for hardware requirements. These are intended only as guidelines, not as absolute performance data, but they will get you in the ballpark for setting up your server.

Table 6.1. Basic Exchange server hardware requirements.

# Users

Processor(s)

RAM

# of Disk Volumes & Type

Up to 100

486/66

32MB

1 standard (for example, Fast SCSI-2)

100–200

Pentium/100

64MB

2 standard

200–500

Pentium/133

128MB

2 disk arrays

500–1000

2 Pentium/166

256MB

2 disk arrays; 1 standard


Technically speaking, according to the product documentation Exchange Server requires an absolute minimum of 24MB RAM. The software will certainly run with this, but Microsoft recommends at least 32MB RAM. Personally, I would not roll out an Exchange Server in a production environment with less than 32MB RAM. For non-Intel based computers increase these minimums by 16MB, respectively.

Assuming your users are light users, these estimates should produce reasonable response times and support your users well enough that you don't have to worry you've either underallocated or overallocated hardware for the server. If they're more intense, you'll need to bump up the hardware a bit more.

The recommendations in the # of Disk Volumes & Type column might not make sense right now, but you learn this later in this chapter, in the section, "Choosing the Right Disk Subsystem." In fact, after reading this chapter you will have a better idea where all these recommendations come from.

With that said, take a few minutes and look more closely at selecting the right hardware. For Microsoft Exchange Server, the processor, RAM, and disk subsystems are the most crucial hardware components in the computer, so they should receive the most attention. The following three sections go into more detail about the issues surrounding the selection of each.



About Exchange with LANs and WANs

Here are a few thoughts on running Exchange on local area networks and wide area networks.

You've probably noticed that the discussion of LAN adapters has been conspicuously absent from this chapter. That's because the network is rarely the bottleneck in an Exchange Server configuration. Exchange Server is very much a client/server system, and its communication mechanisms have been optimized so they approach theoretical minimums.

With that in mind—and given that client/server applications are less network-intensive anyway—you will be best served by a high-performance network adapter, such as a PCI or EISA bus master card. These types of adapters rarely become a bottleneck, presuming you will be running at least a 10 Mbit/sec Ethernet network. If you are running Token Ring, 16 Mbit/sec is preferable. Again, choose a PCI or EISA bus master card. Of course, if you can run a 100 Mbit/sec network, that's great; the chances are even less that your LAN will be the source of a bottleneck.

Now, things change a bit when running Exchange Server on a WAN. There are a couple considerations here. If you're using Remote Access Services (or Dialup Networking in Windows 95), you should naturally use the fastest modem available. In virtually all cases, that will be the main bottleneck in the system. The main exception is if you have many remote users pounding on an Exchange Server equipped with very modest hardware. Still, Exchange is surprisingly fast over a modem using RAS, especially at 28,800 bps under Windows NT or Windows 95.

The other WAN consideration is how your LANs are connected if you have a geographically dispersed organization. If you have a fast link such as a T1, that is a perfect scenario to split into two Exchange Sites joined by the T1. Because the T1 is considered a fast link, you can use the Exchange Site Connector to connect your two sites and maximize the performance of inter-server and inter-site traffic. Again, this type of link could technically be a "bottleneck," but I use the term loosely here because performance between two geographically distant sites is likely not to be as good as on a LAN anyway—at least not yet.



Choosing the Right Processor


The first thing to realize about Microsoft Exchange Server is that among disk, RAM, and CPU, Exchange tends to consume CPU resources the most. That is to say, as load increases, Exchange Server will typically bottleneck on the CPU before the disk or the RAM.



When I speak of "CPU" or "processor," I'm not limiting it to a single CPU. These days, it is not uncommon for a server's CPU subsystem to be comprised of one, two, or more physical processor chips. What I'm actually referring to is whether the CPU resource is one or more physical processors. Of course, the more processors in the system, the more CPU resource Exchange Server has at its disposal because of Windows NT's capability to exploit multiple processors. And Exchange Server does a great job of taking advantage of this Windows NT benefit. As of this writing, Exchange generally does well up to four CPUs in a symmetric multiprocessor (SMP) system. Exactly how well it does depends on many things, such as the architecture of the computer and what types of tasks Exchange Server is performing. However, I would reserve three and four CPU configurations for very large enterprise Exchange servers with complex configurations supporting many hundreds of simultaneous users.


Effect of the Processor on System Performance


The effect the processor has on system performance is twofold.

First, it speeds up the response time for the user. Making the system run as fast as it possibly can speeds up the execution of Exchange's many server processes. That makes things snappy for the user, which makes the users happy, which makes you happy—especially if your boss is one of the users.

Second, the processor provides user scalability. That is, it gives the server the capability to handle an increasing number of users without compromising response time. This is especially true of multiprocessor systems. If you consider the architecture of the Exchange server itself, you will find that it is a multiprocess, multithreaded entity. The Microsoft engineers designed Exchange's server components with multiprocessor systems in mind, so the design lends itself well to that.

A benefit from this multiprocessor-aware design is that when the processor becomes the bottleneck, you can relieve it by adding another processor to the system. This is no small accomplishment. In fact, it is something the personal-computer industry has been waiting a number of years for. And now we have Microsoft Exchange Server as a real-world application, which was created to leverage this technology.

Guidelines for Selecting the Processor


With these ideas in mind, the following are some general guidelines for selecting the right CPU for the job. They are especially applicable for sites supporting hundreds of users per server, or more. Some guidelines might seem intuitively obvious. That's good; you're in the right mindset. However, it is worth listing them anyway. Maybe it will jog some other ideas in your mind.

You can also read more about CPU optimization, bottlenecks, and more in the Windows NT 3.51 Resource Kit. It is an excellent guide for learning about general performance under Windows NT, and that information will be directly applicable to Exchange Server.

Choosing the Right Disk Subsystem


There is much to be said on the subject of the disk subsystem in Exchange. Basically, there are three main areas to understand.

Regarding the third bullet, I will especially note the benefit hardware array controllers. One other subject pertaining to disk arrays that will be addressed is fault tolerance. Disk fault tolerance is a key component of making a reliable Exchange server. And that's what we all want, right?

Exchange Buffer Cache and Disk I/O


The first thing to know with Exchange is that the amount of RAM and the amount of disk I/O are related. That is, more RAM in the system helps to minimize disk I/O—to a point. This is because RAM is allocated to Exchange's database buffers, also called the buffer cache.



This cache is not to be confused with NT's system cache. Although it serves a similar purpose, it is completely separate. In fact, Exchange doesn't even use the NT system cache for disk I/O. Instead, it builds and maintains its own buffer cache using the RAM you have installed in the system. The net effect is the NT system cache is left with very little RAM, about 5MB or less.

A large buffer cache will result in more cache hits, meaning fewer trips to the physical hard drives to read or write data. Naturally, there is a point of diminishing returns limit to this. You can't just keep adding RAM until there is no more disk I/O, but you can use this approach to help relieve a potential bottleneck on an otherwise moderately performing disk subsystem.

Figure 6.1 depicts a hypothetical example of this idea, just to give you a feel for what I am talking about. The actual cache hit rates your Exchange server experiences will vary based on several variables, including number of users, size of database, and type of usage profile.

Figure 6.1. As the Exchange server database buffer cache increases, adding more memory to the cache creates a point of diminishing returns.

Configuring Your Disks for Exchange Server


This section is especially important if you are using Exchange to host a large number of users—in the hundreds or more.

First, you must know that under the covers, Exchange is actually run by a full-fledged database engine complete with a database store and a transaction log. This engine is not unlike a commercial database system such as Oracle or MS SQL Server. Therefore, it is beneficial to apply similar performance techniques to the Exchange server computer.

The basic idea is to separate the drive where the transaction logs are kept from the drive where the database store is kept. Figure 6.2 shows how this should be done.

Figure 6.2. Split the Exchange Server logs and store between two separate disks.

The reason for doing this is that the log is constantly written to and rarely read from—and those writes are all sequential writes. Exchange is just logging all the transactions as they happen—sequentially—in this file. For optimal performance, the system should be configured so this sequential writing is not interrupted, and placing the logs on their own dedicated volume is the best way to accomplish this.



It is always best to configure your Exchange logs on a fault-tolerant volume. The database logs are your lifeline to re-creating the database store should something get hosed in the store. Therefore, it is extremely important to consider a fault-tolerant volume for the logs; it can make your life easier by minimizing the chance of losing valuable data on your Exchange Server machine. I recommend a mirrored (RAID-1) volume for the logs. It provides the best fault tolerance coupled with good sequential write performance. RAID volumes are covered in better detail in the next section, "The Benefit of Disk Arrays."

As for the store, in contrast to the logs, its disk I/O is very random. Data is constantly being read from or written to various places in the database, which makes the I/O patterns unpredictable. You never know if you will get a read or write, whether it will be at the beginning of the database, the end, or somewhere in the middle.

If you placed the store and the logs on the same physical drive, the nice sequential writing to the logs would be repeatedly interrupted by the random I/O to the store. In a large Exchange server with many users, this scenario can hinder performance and potentially cause the disk subsystem to become a bottleneck before it should.

The Benefit of Disk Arrays


You might already be familiar with the concept of disk arrays, commonly referred to as Redundant Array of Inexpensive Disks (RAID). If so, that's fine. You already know the performance benefits. If not, here's an overview of the concept and how it applies to Exchange performance.

First, look a few common RAID configurations:



Use a Hardware Array Controller if Possible

Consider using a hardware drive array controller. This will provide all the same benefits from striping as described earlier. However, there will be the additional performance advantage because it is implemented in hardware. This way you won't have to bother with configuring NT's software striping support—one less thing to worry about when you install NT. Simply configure the controller itself for striping and let it do the work. To NT, a stripe set on an array controller will just look like a single disk volume.

An array controller should have its own on-board processor dedicated to handling the stripe sets. The server's processor and operating system should not incur the overhead of managing the stripe set, and they can be left alone to do their job of serving your Exchange users. Also, the controller should be available in an EISA or PCI version for optimal performance.

An array controller should enable mirroring of more than two drives. With this approach, you get the performance benefits of striping combined with the fault-tolerance benefits of mirroring. For example, you could install six drives in your system, three mirrored with three. Both sets of three would be striped for performance and mirrored for fault tolerance. Although it requires more drives to achieve the same disk space as RAID-0 or RAID-5, it is the best overall performing fault-tolerant scheme, especially for write-intensive applications.

An array controller should have some on-board cache. This fast memory cache is located right on the array controller itself, and accessing cached data from it will be extremely fast—much faster than using NT's System Cache. The controller uses its cache transparent to the operating system, and it is managed by the controller rather than by NT. All this adds up to less overhead on the operating system and the server resources.

Finally, although you're using an array, you should still set up two separate logical volumes so you can split the logs and the store, as described earlier in the section, "Configuring Your Disks for Exchange Server." The effect of doing this is you will get the benefit of array performance on both log I/O and database store I/O. Don't forget to set up your logs on a fault-tolerant volume such as RAID-1.



Choosing the Right Amount of RAM


Microsoft Exchange Server can use any amount of RAM you throw at it—anywhere from the recommended minimum of 32MB up to 512MB, 1GB, or whatever your server hardware can support.

RAM is used for several things in a Microsoft Exchange Server system, and it will be allocated in various ways by the operating system.

Windows NT Server Needs Memory


Windows NT needs a certain minimum amount of RAM for itself—usually in the neighborhood of 16MB for Windows NT Server v3.51. This 16MB is made up of the different Windows NT processes such as CSRSS, LLSSRV, LOCATOR, LSASS, RPCSS, SCM, SERVICES, SMSS, SPOOLSS, SYSTEM, and WINLOGON.

Included in this 16MB minimum will be some memory allocated to the NT System Cache. Exchange Server doesn't actually use the NT System Cache for disk I/O because it has its own. And even though the network-caching aspect of the System Cache is useful, it is not nearly as beneficial to the system as the Microsoft Exchange Server database buffers. Naturally, you want more memory allocated to the buffers, not the System Cache.

You can minimize the NT System Cache size by selecting Maximize Throughput for Network Applications. With this setting, NT will page memory used by the System Cache before it will page memory used by applications such as Exchange Server.



Windows NT Server 3.51 automatically chooses Maximize Throughput for File Sharing when it is first installed. However, the Exchange Server Setup program automatically changes it to Maximize Throughput for Network Applications for you.

You find the Maximize Throughput for Network Applications setting in the Control Panel, as illustrated in Figure 6.3.

Figure 6.3. You can adjust overall system performance in the Control Panel's Network applet.

From the Control Panel, start the Network applet. In the Installed Network Software list box, click the Server entry, and then click the Configure button. A dialog box appears that gives you some radio button options; click Maximize Throughput for Network Applications. Selecting this option helps NT make decisions when choosing what to page to disk when it needs memory. When you choose this setting, if NT needs to page it will tend toward leaving system processes such as Exchange Server in memory, and it will page the NT System Cache. That's what you want; Exchange Server doesn't use the System Cache much.

Exchange Server Needs Memory


There are four main processes that comprise Microsoft Exchange Server. Depending on the configuration of your Exchange Server software, there may be more, but these four are the basic components that all Exchange Servers will have. These run as Windows NT services, and the following list gives the service name followed by the description:

These all require some amount of memory at start-up time—usually 10-15MB just to start these four services. Furthermore, as the system runs and is put under more stress, these will tend to use more memory depending on what is happening in the system. This is especially true of the Information Store. If you have adequate memory in your system, it is not uncommon to see the Store's working set jump to 50MB with a couple hundred users. Fortunately, you can monitor the memory usage for all these processes with the Process object in Windows NT Performance Monitor. That way, you can get an exact picture of how much memory each service has in its working set in your specific installation. For a listing of some useful Performance Monitor counters, including working set, see the section later in this chapter, "Windows NT Objects and Counters in Performance Monitor."

There might also be services running for other Exchange Server options you have installed, such as Internet Mail Connector, Key Manager, MS Mail Connector, or Directory Synchronization (DXA). These require memory too—at least 1-5MB each.

The Exchange Server Database Buffers Need Memory


The Exchange Server buffer cache is comprised of a number of 4KB database buffers. As you learned in the earlier section, "Exchange Buffer Cache and Disk I/O," disk I/O and the amount of memory in your machine are related. This is definitely a key aspect of performance, and it will figure into your decision of how much memory to put in the system.

Look at an example of how additional memory might be allocated to the various parts of the system, especially the database buffers. As you add memory to the computer, the following two tables illustrate how the Exchange Optimizer allocates memory.

For example, say you want to support 200 simultaneous users on your server. They will use private and public stores, and there are 800 total users in the organization. Based on recommendations from Microsoft Exchange Optimizer, Table 6.2 gives an idea of how memory might be allocated to the three main consumers of memory in Microsoft Exchange Server: the NT Server and Exchange Server system processes, the Exchange Server database buffers, and the Exchange Server directory buffers.

Table 6.2. An example of Exchange Server memory usage.

Memory

System Processes

Database Buffers

Directory Buffers

32MB

29MB

2.5MB

0.5MB

64MB

47MB

14MB

3MB

128MB

71MB

53MB

4MB

256MB

119MB

133MB

4MB


Although the exact mix changes somewhat depending on your Exchange Server configuration—the number of users supported, whether you use private and public stores, and so on—Exchange makes good use of the RAM you give it. For example, if you have 256MB of memory for your server, or more, Exchange will put it to work.

To illustrate this, take the example one step further. Say you want to support 600 simultaneous users per server, using public and private stores, and there are 5,000 total users in the organization. Table 6.3 shows how the memory allocation might change to accommodate these changes. Again, this is based on recommendations made by the Microsoft Exchange Optimizer.

Table 6.3. An example of Exchange Server memory usage supporting more users.

Memory

System Processes

Database Buffers

Directory Buffers

32MB

31MB

0.8MB

0.2MB

64MB

56MB

7MB

1MB

128MB

81MB

39MB

8MB

256MB

128MB

106MB

22MB


See how memory is shifted to system processes when there is less system memory? And as you increase system memory, Exchange Server puts it to work in the buffers and in the system processes to prevent paging. Plus, with more total users in the organization, the directory buffers get additional memory. In contrast, shown earlier in Table 6.2, with fewer users the directory buffers peak at 4MB. Perhaps this helps demonstrate the importance of memory to the Exchange buffer cache and to the NT system processes.



To properly optimize the usage of your server's memory, use the Microsoft Exchange Optimizer, called PerfWiz for short because that is the name of the executable: PERFWIZ.EXE. This invaluable utility examines your server's resources and makes decisions about how to allocate memory, disk, system threads, and so on. For more detail about PerfWiz, read the section in this chapter on Exchange Optimizer.


Anything Else You Run Needs Memory


This is an obvious statement, but you'd be surprised how many folks just skip right over this idea without thinking about it. For example, if your Microsoft Exchange Server functions as a Domain Controller—either Backup or Primary—it will have to use a certain amount of memory to support that function. The NT Server SAM and its database will take up some memory as well. Also, if you are logged in to the NT Console of your Exchange Server, that will take some extra memory. Each command prompt requires memory. Any console application you might run, such as NT Performance Monitor, also requires memory and imposes CPU overhead.

Bottom line: You want to stay off the server console if possible. Don't even log on; just let Windows NT Server boot and sit at the logon prompt. The Exchange Server processes will start automatically and without any intervention on your part. In fact, with servers handling hundreds of users, you should consider dedicating the machine explicitly to Exchange Server. For most functions an Exchange server performs, there isn't really a need to logon anyway—just let it serve.

Microsoft Exchange Optimizer


One area into which Microsoft has put a lot of effort is optimizing Exchange Server performance. Microsoft Exchange Server is an intricate piece of software with many features and capabilities. However, along with that goes an unavoidable degree of complexity when you are trying to configure it for the best performance. Wouldn't it be great to have a tool that can examine your system's resources, know what parameters in Exchange Server need to be tweaked, and set those parameters for you automatically?

Enter Exchange Optimizer, or PerfWiz for short. (The two terms can be used interchangeably, so I'll reference both.) The engineers at Microsoft have invested a significant amount of research and development into creating a tool that will do precisely that—and with a minimum of user intervention. In the spirit of wizards found in other Microsoft applications, PerfWiz asks a few key questions, runs some tests on your hardware, and then makes recommendations based on what you told it and what it found.

Typically, you run PerfWiz after the Exchange Server Setup program has finished; Setup prompts you to run it at the end of the installation process. You can also invoke PerfWiz on its own at any time. This is an especially good idea if you have just upgraded or changed any hardware in the system. Any time you add (or remove) RAM, upgrade the processor, or reconfigure the disk drives, be sure to run PerfWiz.

This section takes a peek at PerfWiz to see what it looks like. Sometimes it's good to know what's coming with a utility like this, so you can be prepared ahead of time for the kinds of questions PerfWiz will ask. In the process, you can get a feel for PerfWiz, for the information you need to give it, and for the information it will give you.



Run PerfWiz with a -v parameter for verbose mode. You can run it from the command line, or you can simply modify the Command Line option in the Program Item Properties dialog box of the Microsoft Exchange Optimizer icon, as shown in Figure 6.4.

The verbose mode provides more detailed information during the PerfWiz run about how buffers and threads will be allocated, disk drive performance, and so on.


Figure 6.4. Here, Exchange Optimizer is configured to run in verbose mode.

A Sample Session with Exchange Optimizer


Take a minute and go through a PerfWiz session. This will give you a feel for what the utility looks like and for what will happen when you run it. You will also be better able to provide the information PerfWiz asks for.

Figure 6.5 shows the opening screen for PerfWiz.

Figure 6.5. Exchange Optimizer will shut down your Exchange Server for optimization after this opening screen.



It is not obvious in Figure 6.5, but notice the last paragraph. When you click the Next button, PerfWiz will shut down all your Microsoft Exchange Server services. This has to happen to alter the Exchange Server system parameters, but be careful if your server happens to be up and running.

The next screen requests some information about how your server will be used.

Say, for example, that you have 800 total Exchange users in your organization who will use both e-mail and public folders. You plan to divide the users over four servers supporting 200 users each. Also, each of the four servers is dedicated to Exchange Server—that is, no other tasks such as file sharing, print sharing, or other applications are required of the server. Figure 6.6 depicts how the selections should look.

Figure 6.6. Optimizer needs some information about how your server will be used.

The information that Optimizer needs is basically broken down into four categories:

The next screen, as shown in Figure 6.7, lists the disk drives in your system and whether they will be considered for storing Exchange Server files. You can exclude any drive automatically by double-clicking on the drive in the list. Also, if there is not enough space on a drive to make it usable, it will be excluded from the list automatically.



The screen in Figure 6.7 appears only if you are running PerfWiz in verbose mode.

Figure 6.7. Drives D: and E: are ready to be analyzed by Optimizer.

After you click Next, the drives are tested using a mix of sequential and random disk I/O. Then PerfWiz will show its performance results for the Random Access (RA) and Sequential (Seq) disk tests as in Figure 6.8. The numbers are in milliseconds, so lower numbers indicate better drive performance for this test.



The screen in Figure 6.8 appears only if you are running PerfWiz in verbose mode.

Figure 6.8. Drives D: and E: have been analyzed by Optimizer.



When you run PerfWiz in verbose mode, the disk test will report a table of numbers for Random I/O and Sequential I/O as in Figure 6.8. PerfWiz uses these to help determine which drives should contain the database store, the database logs, the directory, and so on. However, these numbers should not be construed as an indicator of absolute disk performance. Therefore, for example, don't panic if PerfWiz says your huge disk array is only one percent faster on Random I/O than your single, nonarray disk drive. The performance numbers produced by PerfWiz are not designed to be interpreted by themselves as a definitive performance measurement of your disk subsystem.

On the next screen, as shown in Figure 6.9, Optimizer makes recommendations about which drives should contain which files.

Figure 6.9. Optimizer makes its recommendations about where to place Exchange Server files.

In Figure 6.9, Microsoft Exchange Server was originally installed on drive E:. PerfWiz is suggesting to move the Store and Directory logs to drive D: and leave the database Store, Directory Service, and MTA on drive E:.

PerfWiz makes these determinations based on three main things. First and foremost, PerfWiz tries to split the logs and the store onto two separate drives if at all possible. Second, PerfWiz tends to place the database store on the drive with the best random I/O (RA) score. Third, PerfWiz tries to place the logs on the drive with the best Sequential I/O (Seq) score. In this case the first and second rules held, but the third one was overridden by the more important option of splitting the logs and store.

There are other variables that factor in the decision, such as drive size and available space, but these three are the most important. Bear this in mind when you are designing a system for Exchange Server.



An array of disk drives, such as one configured with a hardware disk controller, will provide much better random I/O performance than a single drive. On the other hand, an array will not necessarily provide better sequential I/O than a single drive. This makes a good case for a volume consisting of one drive mirrored with an identical drive for the logs, and a volume consisting of a RAID array for the store.

You're almost finished with PerfWiz. On the next screen you can allow the system to automatically move the files for you in accordance with the recommendations in Figure 6.9. This is usually a good idea so that no files get omitted.

The final series of screens deals with the meat of PerfWiz—the Microsoft Exchange Server parameters. There are four screens of system parameters, shown in Figures 6.10 through 6.13.



The screens in Figures 6.10 through 6.13 appear only if you are running PerfWiz in verbose mode.

Figure 6.10. The first screen of Exchange Server system parameters.

Figure 6.11. The second screen of Exchange Server system parameters.

Figure 6.12. The third screen of Exchange Server system parameters.

Figure 6.13. The fourth screen of Exchange Server system parameters.

As you can see, there are several parameters. Some of them will be altered a lot, some of them not at all. You can change PerfWiz's suggestions, but I do not recommend it. Microsoft has spent a lot of time tweaking and testing these parameters to get the right mix. And you can really mess up your Exchange Server performance if you aren't careful. That's why PerfWiz exists.

I hadn't planned to explain the purpose of every parameter shown in Figures 6.10 through 6.13, but I do want to point out two important ones: "# of information store buffers" and "# of directory buffers." These are arguably two of the most important Exchange parameters. Having them sized properly for the amount of RAM in the server will help optimize performance. Size them improperly, and your performance will immediately go down the tubes. Too large, and the system will start paging excessively and thrash itself to death. Too small, and Store I/O will be choked off and your system will become disk-I/O constrained. Again, this same idea applies to all the other parameters, too, so if you decide to play around be careful!

Both parameters represent a quantity of 4KB buffers. In the case of the Information Store parameter, these buffers are used to hold information being read from or written to the private or public database. It actually performs the function of a disk cache dedicated to the database. So here the Information Store—that is, the private and public databases—will have 1,305 buffers allocated for it. That figures to 5,220KB of buffers, or just a little over 5MB of system RAM.

The same idea applies to the directory buffers.



To give you a feel, these numbers came from a system with 48MB RAM. As you increase the amount of RAM in your system, notice how these numbers change. Refer to Tables 6.2 and 6.3 earlier in this chapter in the section, "The Exchange Server Database Buffers Need Memory" for an example of how RAM is allocated as you increase system RAM.

Next is the final screen of PerfWiz. At this point, if PerfWiz stopped your Exchange Server services at the beginning, it will restart them for you. If you ran PerfWiz with the Exchange Server services already stopped, it will not restart them for you.

One final note. The activity during the PerfWiz session is logged in a file called PERFOPT.LOG, stored in your SYSTEM32 directory. This is a cumulative log; every PerfWiz run is logged.

Windows NT Performance Monitor Counters


If you have been around Windows NT for any length of time, you have probably played around with—or actually used—Windows NT Performance Monitor (PerfMon). There are many performance counters contained in PerfMon, and these counters can provide you detailed information on how various systems within Windows NT are performing.

To help you wade through the myriad of counters, this section has a few good ones that will get you started. These counters should prove useful when you are monitoring the usage and performance of Microsoft Exchange Server. The exact counters you use will vary some with your exact implementation; for example, you might not use NetBEUI, so NetBEUI-specific counters won't be useful to you. Regardless, the general principle is the same—and you can use these counters to begin some exploration on your own.

In this section you find two groups of counters: the Exchange-specific counters, which are installed when Exchange Server is installed; and the generic counters, which are installed as a part of Windows NT Server.

Although these are only a few of the many counters available, this list should get you started exploring the PerfMon counters for yourself. There is a wealth of information to be gathered.



Don't forget to run diskperf -y from a command prompt to activate the PerfMon disk counters before trying to use the Logical Disk (and Physical Disk) object. You can also activate the disk counters via the Devices applet in the Control Panel. Find Diskperf in the list, and set its Startup Type to BOOT. With either method, you must restart your machine for the change to take effect.


Exchange Server Objects and Counters in Performance Monitor


Some applications have their own performance objects—containers for the performance counters. These make life much easier when you are tracking performance or system behavior because they provide specific performance information on components within Windows NT. Table 6.4 lists the Exchange-specific objects that are automatically installed in Performance Monitor during setup.

Table 6.4. Exchange objects installed in Performance Monitor.

Object Name

Description

MSExchangeDB

The object that contains counters pertaining to the Exchange Server database engine (DB)

MSExchangeDS

The object that contains counters pertaining to the Exchange Directory Service (DS)

MSExchangeIS

The object that contains general counters for the Exchange Server Information Store (IS)

MSExchangeISPrivate

The object that contains counters pertaining to the Exchange Private Information Store

MSExchangeISPublic

The object that contains counters pertaining to the Exchange Public Information Store

MSExchangeMTA

The object that contains counters pertaining to the Exchange Mail Transfer Agent (MTA)

MSExchangeMTA Connections

Connections object that contains counters pertaining to connections to the MTA


There are dozens of Exchange Server counters included in these seven objects. Table 6.5 contains some useful counters to get you going.

Table 6.5. Useful Exchange Server counters.

Object Name

Counter

Description

MSExchangeDB

% Buffer Available

(Instance=Information Store) The percentage of the database buffer cache that is available for use. This counter and the following one help monitor how effective your database buffer cache is.

MSExchangeDB

% Buffer Cache Hit

(Instance=Information Store) The percentage of requests for store data that were satisfied from the database buffer cache.

MSExchangeIS

User Count

The number of users connected to the store.

MSExchangeISPrivate

Messages Submitted/min

The rate messages are being submitted by clients. A rate consistently higher than Messages Delivered/min could indicate the server can't keep up with delivery load.

MSExchangeISPrivate

Messages Delivered/min

The rate messages are delivered to all recipients. A rate consistently lower than Messages Submitted/min could indicate the server can't keep up with delivery load.

MSExchangeISPrivate

Send Queue Size

The number of messages in the send queue. Another counter that can indicate when the server is overloaded.

MSExchangeISPublic


(same counters as MSExchangeISPrivate)



Windows NT Objects and Counters in Performance Monitor


Following are some of what I call generic counters that are installed as a part of Windows NT. Again, Table 6.6 contains a list of some objects and counters I have found useful when keeping an eye on Windows NT.

Table 6.6. Generic objects performance monitor.

Object Name

Description

Cache

The object that contains counters pertaining to the Windows NT System Cache

Logical Disk

The object that contains counters pertaining to the logical disk drives in the system

Memory

The object that contains counters pertaining to memory usage in the system

Paging File

The object that contains counters pertaining to the status of the pagefile

Processor

The object that contains counters pertaining to the system processor(s)

Server

The object that contains general counters pertaining to the server service of the system

System

The object that contains general counters pertaining to the operating system


Again, there are dozens of counters included in these objects. Table 6.7 contains some useful counters to get you going.

Table 6.7. Useful generic counters.

Object Name

Counter

Description

Cache

Data Map Hits %

The percentage of successful references to the in-memory system data cache.

Logical Disk

% Disk Time

The percentage of time the disk is busy servicing I/O requests.

Logical Disk

Avg. Disk sec/Transfer

The average amount of seconds it takes the disk to satisfy a disk transfer (read or write).

Logical Disk

Disk Bytes/sec

The rate at which data is transferred to or from the disk during I/O operations.

Memory

Available Bytes

The amount of virtual memory in the system available for use.

Memory

Cache Bytes

Size of the NT System Cache. Note that the system cache is for both disk and LAN.

Memory

Pages/sec

Indicates overall paging activity—the rate at which pages are written to or read from the disk.

Paging File

% Usage

Shows what percentage of the pagefile is in use. Could indicate if you need to increase your pagefile.

Processor

% Processor Time

Amount of time the processor is busy doing work. This is User and Privileged time combined.

Process

Working Set

Shows the number of bytes in the working set of the selected process (Instance). A working set of memory is memory that was recently used by threads in the process, that is, the set of memory with which the process is currently working.

Server

Bytes Total/sec

The rate at which the server is sending data to and receiving data from the network.

System

Processor Queue Length

The number of threads waiting in the processor queue. Values consistently above 2 can indicate processor congestion. (You must also monitor at least one thread from the Thread object for this counter to be nonzero.)



Simulating a User Load with LoadSim


This entire chapter focuses on subjects surrounding the system requirements of Microsoft Exchange Server. One way to effectively go about addressing this is to have a method for placing a predictable, reliable, repeatable load on Exchange Server so its performance can be measured. Microsoft Exchange Server Load Simulator (LoadSim) is a tool that provides a method to do precisely that.

Figure 6.14 shows an example of a LoadSim screen. In this case, LoadSim is simulating 100 simultaneous Exchange users using a single Windows NT Workstation machine.

Figure 6.14. LoadSim is simulating 100 Exchange users.

Appendix A, "Understanding and Using LoadSim," covers the implementation and use of this utility in detail. Also, included on the Exchange Server CD is a LoadSim document from Microsoft describing LoadSim. If you plan to use LoadSim, I highly recommend reading both Appendix A and the Microsoft document. My purpose in this section is not to rehash what is covered elsewhere. I mainly want to bring the existence of the utility to your attention and encourage you to look at it closer.

A lot of attention has been paid to the development of LoadSim, and it has proven itself a valuable tool in testing Microsoft Exchange Server and in validating server configurations. The tool provides a way to simulate multiple Exchange clients using a single machine. For example, a single Pentium-based Windows NT machine could simulate 100 users, all simultaneously performing e-mail, public folder, and Schedule+ tasks against the same Exchange server. LoadSim logs data about the activities of its simulated clients that you can use to analyze the performance of a server. When you know how to use it, LoadSim is a powerful tool to have at your disposal.

Summary


Performance and system requirements are always an interesting subject to talk about. It's even fun to debate it with colleagues from time to time. There might even be some items in this chapter that you would want to debate with me. No problem, at least I got you thinking about it. And that is part of the goal.

Regardless, the topics in this chapter are crucial to grasp if you have responsibility for deploying Exchange servers, especially if each server is to support a few hundred users. Topics such as server capacity, the proper CPU types, the benefits of multiple CPUs, disk subsystem configuration, fault tolerance, the proper amount of RAM, PerfMon objects and counters, and LoadSim are all important considerations during the process of planning your server rollout.

Most of the discussion assumes each Exchange server must support a number of users in the hundreds. In fact, many of the performance and optimization techniques in this chapter don't really matter that much if you have a very small—about 25 users or less—installation. However, some ideas, such as disk fault tolerance and CPU selection, are relevant no matter what size installation you have.

This chapter covers quite a few topics, including the following:

First, you learned how many users Exchange Server will support. You discovered there is not a straightforward answer to this question, but there are some definite issues to explore that help answer the question for the most important installation—yours.

Next, you learned concepts related to planning the components (such as CPU, disk, and RAM) in the main subsystems of your server.

After that, you took an advanced peek at the Microsoft Exchange Optimizer. You got a feel for some of the questions it will ask you and for some of the parameters it configures—before you start the Exchange setup program.

Finally, the chapter ends with a discussion of two tools helpful to understanding Exchange Server performance: some common objects and counters in Microsoft NT Performance Monitor, and Microsoft's client load simulator utility LoadSim.

By now you should understand general implications of performance on your Exchange server's hardware requirements. Also, you should have some general ideas about how to set up Exchange for good performance before the installation process begins. Finally, you should have a better idea of how to apply Performance Monitor and LoadSim to the task of understanding Exchange performance.

The next chapter examines some other aspects of planning your installation. And when you are considering things such as multiple servers and single- and multiple-site installations, the concepts presented in this chapter will prove useful.

Previous Page Page Top TOC Next Page