There are three steps to fine-tuning your server performance (it's a never-ending process):

1. Collect your data.
   
2. Analyze your data.
   
3. Take further corrective steps.
   

Now I'm going to get controversial: I do not recommend defining baseline performance standards. I realize that it's the conventional thing to do, but at the same time I think you can waste a lot of time and effort by dickering over what an acceptable average time to send a message is. For the purposes of this discussion I'm going to assume that you're already running an Exchange server and that the goal is simply to make it as fast as it can be within the parameters of what you're working with—in terms of equipment, budget, etc. So I'll let your initial data collection process set your baselines—your goal is to be faster than however fast you are now.

Collecting Your Data

It's impossible to know how to get somewhere if you don't know where you are. Data collection is the art of finding out where you are. Once you've determined where the bottleneck in your system is you can figure out how to fix it.

Fortunately, one of the best tools for data collection in an Exchange/NT environment comes with NT: the Performance Monitor. If you're not familiar with it, I encourage you to spend some time getting familiar with it, because it's an excellent tool for gauging the general health and well-being of your NT servers. If you run an NT or Windows 2000 workstation, you can run Performance Monitor right from your desktop and monitor any of the servers you have appropriate access to across the network. I often have Performance Monitor running in the background on my Windows 2000 Professional workstation with charts, logs, or alerts monitoring the health of my various servers.

The first thing to check on an Exchange server is the memory. Because NT makes use of virtual memory—paging physical memory out to disk—problems that appear to be CPU- or disk-related might actually be caused by insufficient memory. So, make sure that you have enough RAM before checking out your CPU, disk, and other settings.

To do this, start Performance Monitor and be prepared to capture at least one entire workday's worth of data. The reason you want to get a whole day's worth is because it's good to see the difference between the "off-peak" hours before many of your users are logged in and the peak hours during the day when most or all of your users are logged in.

Switch to Log view and add these three objects to the log: Memory, Paging File, and Process. Click Options > Log, give the log file a name, and click Start Logging.

NOTE: For best results, you may want to change the interval from the default 15 seconds to 5 seconds.

One word of caution: this log file can get pretty big, pretty fast (log files of 75MB or more are not unheard of). Make sure you have sufficient disk space to store it, or consider locating the log file on another drive where you do have enough space.

Once you've collected your workday's worth of data, click Options again and stop the log. Now switch to Chart view, click Options, and Data From. Select the log you just created. Now if you click the Add Counter button you'll be able to choose from the objects that you had selected to log.

Analyzing Your Data

The first counters you need to check are "Memory: Available Bytes" and "Memory: Pages/Sec." As you've probably surmised, the first counter merely shows you how much free physical memory (RAM) your system has. The second counter shows you how often your system looked for something in RAM but had to go to virtual memory (the hard drive) to find it.

If you have configured your server to Maximize Throughput for Network Applications (Control Panel > Network > Services > Server > Properties)—and you should have it set this way for Exchange—then your Available Bytes should stay above 4MB for optimal performance. If you have configured your server to Maximize Throughput for File Sharing, then you should keep the Available Bytes above 1MB for optimal performance. If your Available Bytes counter is not maintaining these levels, that would indicate that you need more RAM to support the load on this server.

The Pages/Sec counter can support that diagnosis. If the average on that counter is above 10, you probably don't have enough RAM. If it's above 20, you are well on your way to a serious problem. Bear in mind that you're interested in sustained numbers here. If your Pages/Sec counter occasionally spikes above 10, that's not necessarily a problem—you're mostly concerned with when the average value is high or when there are sustained periods where the value stays above those thresholds.

If your Pages/Sec counter is unusually high and you want to know which process is suffering the most from this problem, you can look in the "Process Object" for the "Page Faults/Sec" counter. Each running process on the server has its own instance and you can add them all (or just the ones you're wanting to check) to your chart and see which is the highest. Take note, however, that a page fault doesn't necessarily mean that the system had to go to disk to find the data. A page fault merely means that the application didn't find the requested data within its own working set of memory.

There are both hard and soft page faults: a soft one means that the data was found elsewhere in memory, while a hard one means the system had to go to the disk drive to retrieve the data. Soft page faults aren't a particularly big problem (unless there is an extremely high number of them) because the data is still retrieved from memory. Other than causing a slight load on the processor, they don't significantly affect performance. Hard page faults, however, are what you're trying to reduce. Hard drives are considerably slower than RAM, so any time the system has to resort to the hard drive to get something that should have been in memory, you will see a degradation in system performance.

It is possible to have a high number of Page Faults/Sec while still having an acceptably low number of Pages/Sec. That simply means that your page faults are soft page faults and that the system isn't having to go to disk very often to access memory pages.

The next memory counter that you should look at is "Committed Bytes." This counter indicates the amount of virtual address space that has been committed to applications. The actual value of this number isn't very useful by itself; instead, what you want to do is compare this value to your actual amount of RAM in the machine. If the Committed Bytes value is larger than your actual physical memory, the server will have to swap the excess out to disk and your paging values will go up. That's an indication that you need more RAM.

The last memory-related counter that we want to check is the "Paging File, %Usage" counter. If you have more than one page file (for example, one on your C drive and one on your D drive) you will find separate instances for each that you can monitor. For simple testing, however, you can simply select the Total instance and it will show you the aggregate usage. This counter shows you how much of your paging file(s) is actually in use. If that number approaches 100 percent, that's an indication of two things:

• You should increase the size of your page files or add additional page files
  
• You have a lot of page file usage and may need to add more RAM
  

If you've decided that you need to add more RAM, you can use the "Paging File, %Usage Peak" counter to give you a hint of how much to add. Multiply the maximum %Usage Peak by the total size of your paging files to determine how many megabytes of paging file are in use. As a rough estimate, that would be a good amount of RAM to add to your system. Note, however, that this is not a hard and fast number; it's merely a general guideline.

In my system that means multiplying .10 (10 percent) times 384MB (the approximate paging file size) to get a result of approximately 38.4. From that, rounding off, if I were to add memory to my server, I'd add 32MB RAM.

Taking Further Corrective Steps

If one or more of these counters indicate that your system is low on memory, you have a few options for how to deal with that problem:

1. The obvious solution is to add more RAM. Although Exchange requires a minimum of 24MB RAM, I can assure you that 24MB is a real minimum. I wouldn't dream of running Exchange with less than 32MB and even that wouldn't be a very pleasant dream. As a general rule, I would start with 64MB and go up from there.

   TIP: If you add RAM to your Exchange server, rerun the Performance Optimizer to let it adjust your Exchange server to take advantage of the extra memory.

2. If adding more RAM isn't an immediate possibility, try reducing the amount of memory that the server is utilizing by shutting down unnecessary services. It's possible that you have services running that aren't required, which could be consuming valuable resources. You might also consider moving other applications, such as SQL Server, off to other servers.
   
3. If you check the "Database Object, Cache % Hit" counter and discover that your cache hits are routinely near 100 percent, you can use Perfwiz -v to adjust the memory that Exchange Server will use. Try revising the number down in small increments and see how it affects your memory counters in the Performance Monitor and Cache % Hit counters. If your Cache % Hit counters drop below 95 percent, it's time to stop reducing the memory settings. (Every time you run Perfwiz, you'll have to stop and restart the Exchange Services, so don't do it during business hours or while you have users logged in and expecting access to their mailboxes.)
   

Exchange loves RAM! Give it as much as it wants and it (and you) will be much happier. In Part II, I'll take a look at the processor, disk, and network issues that you need to look at to optimize Exchange.