Some of the main topics in this chapter are
Server performance is a visible and critical issue. If your server is performing poorly, chances are good that quite a few people know about it. The visibility resulting from poor performance is not your only concern; poor performance can strongly affect the ability of your company to compete. It's clearly important to resolve performance problems quickly and make sure that you're getting the maximum benefit possible from your hardware.
Another perspective on performance optimization is to get the most performance from the hardware and software you have. You're not fixing a specific performance problem, but you're making both the hardware and software perform at their peak, possibly postponing the time when you'll have to upgrade the hardware.
The first step in resolving a performance problem is finding out that there is a problem. There are different ways of going about this, and you won't always have control over how you find out about a problem. The trick is to find out about problems proactively. That means that you discover a problem before most (if any) users.
This doesn't mean that you'll never learn about a performance problem from a user. In fact, developing a good relationship with end users is important in this process. There are few people who have a better gut-level understanding of the performance of your system than the people who use it every day.
End users have the ability to complete their jobs in a timely manner, dependent on the performance of the server. End users use the server day in and day out, often performing the same function on a server over a long period of time. All these factors give end users some expertise on the performance of the server.
Information Systems (IS) people often only have the ability to complete their jobs in a timely manner, dependent on the system sitting on their desktops. IS people often don't sign on to certain servers unless there's a problem and often perform different tasks every day of the week. Therefore, someone in the IS department might be the worst person to turn to for an impression of the performance of a server.
You can build rapport with end users in various ways:
The worst thing you can do, though, is develop a system in which you only know about problems because of complaints. It's always better to resolve performance problems before they are known about either at all or by all.
Another good way to find out about performance problems on your servers is to create a structured and centralized method of reporting performance information. Structured, in this case, means that the performance data from all your servers is gathered on a routine basis. Centralized means that all the data is gathered on one system for you to review.
One of the most important pieces of information that you need to have about your environment is the day of week and time of day when your servers are most heavily used. You can get that information at least a couple of ways.
One way is to have a good understanding of the way your business works. Are shipments received at certain times of the day? Chances are, the receiving software and database will be heavily used at that time. Do most of your customers tend to order at night? Then your order entry system and database will be most heavily used during the evening hours. Those are the kinds of questions you need to answer. Managers of different departments can, and often will, help you gain a better understanding of those issues.
You can also get an understanding of the load placed on your systems by routine monitoring. Keeping track of some basic performance information--such as processor, disk, memory, and network utilization--can help. Until you have a good understanding of the normal workload of your systems, you might want to routinely run the Performance Monitor to gather that information (see Chapter 38, "Monitoring NT Server").
Another important point to remember is that the workload changes. If a year ago you understood the workload placed on your servers at various times of the day, that might have changed. For example, maybe the receiving department has changed the hours that it accepts shipments. Or perhaps your company is offering specials to customers who place orders in the morning. Workload changes are something you need to review from time to time.
The next question is how you go about automatically monitoring the performance of your servers. The best way I know of is to use the AT command in conjunction with the MONITOR command. Using these two commands enables you to schedule the Performance Monitor to collect alert and log information at regular intervals.
The AT command schedules commands and programs to run on a computer at a specified time and date. The Schedule service must be running to use the AT command. Here's the syntax (see Table 39.1):
AT [\\computername] [ [id] [/DELETE] | /DELETE [/YES]]
AT [\\computername] time [/INTERACTIVE]
[ /EVERY:date[,...] | /NEXT:date[,...]] "command"
Table 39.1 Parameters of the AT Command
| Option | Description |
| \\computername | Specifies a remote computer. Commands are scheduled on the local computer if this parameter is omitted. |
| id | An identification number assigned to a scheduled command. |
| /DELETE | Cancels a scheduled command. If id is omitted, all the scheduled commands on the computer are canceled. |
| /YES | Used with deleting all scheduled jobs and when no further confirmation is desired. |
| time | Specifies the time when the command is to run. |
| /INTERACTIVE | Enables the job to interact with the desktop of the user who is logged on at the time the job runs. |
| /EVERY:date[,...] | Runs the command on some specified day(s) of the week or month. If date is omitted, the current day is assumed. |
| /NEXT:date[,...] | Runs the command on the next occurrence of the day (for example, next Thursday). If date is omitted, the current day is assumed. |
| "command" | The Windows NT command or batch program to be run. |
The MONITOR command is supplied with the Windows NT Server Resource Kit from Microsoft. Here's the syntax of the command:
Performance Data Logging Service Configuration Tool
Copyright 1994, Microsoft Corporation.
Version 1.0 (94.05.04)
Service is set to use configuration file: No configuration file.
Service is STOPPED and set to MANUAL startup mode.
Commands Summary:
Monitor [\\computer] Setup - Setups the datalog service
Monitor [\\computer] <File Name> - Sets the service to use a configuration file
Monitor [\\computer] Start - Starts the service
Monitor [\\computer] Stop - Stops the service
Monitor [\\computer] Pause - Pauses the service
Monitor [\\computer] Continue - Restarts the service
Monitor [\\computer] Automatic - Setups service to start automatically at boot time
Monitor [\\computer] Manual - Setups service such that it requires to be manually started
Monitor [\\computer] Disable - Disables Service
Monitor [\\computer] - Displays of current service setup and status
Monitor -? - This help screen
Note: If [\\computer] is not specified, local machine is used.
You can use the AT command to run the monitor at certain times of the day. Another option is to collect data, starting when Windows NT Server starts. This is called automatic collection.
Here's an example of scheduling the performance data logging service to run on a regular basis:
2. Copy the DATALOG.EXE program to the same directory.
TIP: DATALOG.EXE, the actual program used to capture performance data, is on the Windows NT Server Resource Kit CD.
4. Let the monitor know which workspace file it should use by entering the MONITOR JIMS.PMW command.
5. Start the monitor by entering the MONITOR START command.
If you want the performance data logged every time the computer is booted, enter
the MONITOR AUTOMATIC command.
Depending on the data collection interval and the data you're collecting, using automatic collection can take quite a bit of storage. However, automatic collection gives you the best picture of the performance of your systems throughout the day. Automatic performance data collection is also often used for capacity planning purposes.
If you're not going to use automatic collection, then you need to combine the AT command with the MONITOR START and MONITOR STOP commands. Here's an example that starts the monitor at 8 A.M.:
AT 8:00 /EVERY:M,T,W,TH,F "MONITOR START"
Strictly speaking, capacity planning doesn't help you find existing performance problems. Rather, capacity planning can help you anticipate performance problems. That way, you can address any underlying resource issue before it hampers the productivity of your users.
The easiest way to go about capacity planning is to collect performance data for your systems over a long period of time (for example, a year). The data collected from the Performance Monitor is often too granular for the purposes of capacity planning, so you might need to write programs to summarize the data. That way, you don't need to keep large amounts of performance data around for long periods of time.
For example, you might pick certain kinds of data from each day's data and summarize it into another file. You might choose the average CPU utilization during business hours, keep the number of times the CPU utilization hit 100 percent during the day, and the CPU utilization during nighttime processing. You can store this data in a file for each day and get rid of the detailed performance data.
Then you might use Excel or some other charting tool to show how CPU utilization was growing over a period of months. From that data, you can better predict when CPU utilization will hit a threshold that requires action. For example, you might decide that when the average CPU utilization during the day hits 70 percent, you need to upgrade the server. From the summary data, you can project that because you're at 50 percent now, and the utilization is growing 5 percent per month, you will need the upgrade in about four months.
That's the easy and inexpensive route to capacity planning. Software is available that is much more sophisticated and might be more accurate in predicting performance problems. One example is TME by Tivoli (http://www.tivoli.com). Most times, however, taking the simplest route is the best way to start capacity planning.
Those are some of the ways you can find or predict performance problems. The next step is to determine the cause of the problem.
Sometimes, finding the cause of a performance problem is fairly easy. You look at the performance data, and the problem is apparent. Other times, the real cause of a performance problem can be much more elusive.
A performance problem can be difficult to isolate for many reasons. Different resources behave differently when they reach their utilization threshold. Sometimes, the resource that's having the problem might actually hide itself and appear as a problem with another resource. Let's first discuss how different resources in a system behave when overused and what the symptoms of overutilization are in each case.
Finding that a processor in a system is over its utilization threshold is usually fairly easy. Figure 39.1 shows the utilization of the processor in a system that is pegged at 100 percent. If you are having a performance problem, it's easy to tell from the chart that processor utilization is probably the cause of the problem.
This processor is clearly overused.
You can see in Figure 39.1 that the CPU utilization is high. The next step is to determine which process or processes are causing the utilization to be so high. My favorite way of doing this is to use the Task Manager (see Figure 39.2).
You can select the Processes tab to see all the processes running. Then, by clicking the CPU column, you can order the processes based on their CPU utilization, which I've done in the Task Manager, as shown in Figure 39.2.
Use the Task Manager to find the process using the most CPU.
You can see in Figure 39.2 that the WINWORD.EXE process is using 92 percent of the CPU. You need to watch these values over a period of time to make sure that you aren't seeing a transient effect. That means you should observe these values for at least a few seconds so that you know the use of the CPU by Word wasn't just short-term.
If you need more information than this, you can also use the Performance Monitor. It can help you break out the information on CPU utilization by User and Privileged mode processing. This information can be useful when reporting a problem with a process to a software vendor.
NOTE: When monitoring CPU utilization, be aware that using the Performance Monitor can use quite a bit of CPU. How much CPU is used by the Performance Monitor varies, based on a number of factors, including the frequency that you're gathering data and what data is being gathered.
When a system starts having a performance problem, many people have a knee-jerk reaction to add memory, thinking that more memory will solve the problem. Although memory is often the least expensive component to upgrade, it's important to make sure that memory is the problem before you add more of it.
Defining Memory Terms. You should be familiar with these terms before you begin diagnosing a performance problem related to memory:
NOTE: Certain pages are marked so that they cannot be moved to disk at any point. Operating system functions and time-critical processes use these pages, for example.
Memory Problems that Look Like Disk Problems. When your system has a memory utilization problem and you start looking at the Performance Monitor, it might appear as though you have a disk utilization problem. In Figure 39.3, you can see what a page faulting problem looks like in the Performance Monitor. The small dotted line that's nearly pegged in the middle of the graph is Percent Disk Time.
I've limited Windows NT Server to just 16M of memory to illustrate a memory utilization problem. You can see in the graph that the page faulting rates are high, but the disk numbers are the ones that probably would grab your attention. You need additional information to help you understand that you have a memory utilization problem.
At this point, you need to determine whether you have a real disk utilization problem or a problem with memory utilization that's masked as a disk utilization problem. One way of finding out is to take a closer look at memory utilization. The tool I most often use in this case is the Task Manager.
The place to start is the Performance tab in the Task Manager, as shown in Figure 39.4. Toward the bottom of the window, there's a good overview of memory utilization. In the Commit Charge frame, you can see that the total memory available is about 40M. This is the combination of physical memory and virtual memory. You can also see that there's only about 8M available, which is extremely low.
Here's a memory utilization problem in the Performance Monitor. The dotted line that seems to be the problem is a disk usage counter. In this case, however, the real problem is memory utilization.
The Performance tab in the Task Manager gives an overview of the memory situation on the system.
Now that you're pretty certain you have a memory utilization problem, the next step is to look at how memory is being used in more detail. You can get this information by using the Processes tab shown in Figure 39.5. In this case, I've selected additional columns that I want to see. All the columns I've selected deal with memory utilization.
The Processes tab shows more detailed information about how each process is using memory. A good starting point is to order the data based on the VM Size field.
The most useful piece of information on this window is probably the VM Size field. When you click that heading, the Task Manager orders the data based on that field. You can then tell which process is using the most virtual memory, in this case--WINWORD.EXE.
Another item I often look at on this window is the number of page faults. Although Word has a high number of page faults--more than 10,000--the 16-bit Windows support process NTVDM.EXE is close behind. I can tell that these two processes are competing for the limited memory.
This is how I start isolating whether the disk utilization problem you saw in Figure 39.3 really is a disk problem or a memory utilization problem in disguise. Now take a look at a real disk utilization problem and discuss how it's different from what you've just seen.
To distinguish between a memory utilization problem and a disk utilization problem, you need to understand what's causing the high disk utilization rates. Is page faulting causing the Virtual Memory Manager to use the drives a great deal? Or is the system or a particular application using the drives extensively?
You can tell the difference by looking at the page faulting rate. On a system where page faulting is not the root cause of a disk utilization problem, the page faulting rate is low. How low is difficult to say because the rate that's considered low depends on the system.
Another number to look at when evaluating whether the drives are the root cause of a performance problem is the disk queue length. High disk utilization isn't necessarily a problem by itself. The performance problem happens when operations for a drive are hung in large queues.
Figure 39.6 shows a typical performance problem caused by disk utilization. Although the CPU utilization and the pages per second are high, it's clear from the data that all other system resources are bound by the drives. Resolving the disk utilization problem, in this case, would probably cause the underlying process to finish more quickly.
This is a typical disk utilization problem. The CPU utilization initially jumps to about 100 percent but then falls off as the performance of the system becomes bound by the drives.
Monitoring drives using RAID or stripe sets varies depending on the hardware you're using and how you have it configured. For example, some hardware-based RAID systems appear to the Performance Monitor as a single drive even though RAID is, by definition, made up of multiple drives. However, the Performance Monitor in general is quite adept at monitoring the performance of drives using RAID, stripe sets, or mirroring.
The only difference when monitoring some forms of protected drives is when you need to collect data. If you're using the FTDISK service to handle I/O with your drives, you need to run the DISKPERF command to start disk performance collection differently. FTDISK is used when multiple physical drives or segments are combined into a single logical drive. You'll find FTDISK in Control Panel's Devices option, and it will be started if you are using it. You can see in Figure 39.7 that FTDISK is not started on my system.
In the Devices dialog box, you find out whether you're using FTDISK or the fault-tolerant disk driver. In this case, I'm not using the driver.
TIP: The Devices panel in the Control Panel is another place where you can tell whether you have disk performance collection enabled. You'll find an entry in the Devices list box named DISKPERF. If your system is collecting disk performance data, the Status will be Started, and the Startup option will say Boot.
Although, normally you don't collect disk performance data, you can use the DISKPERF command to do do so. You need to run the following command:
DISKPERF -Y
Running this command causes the system to make disk performance data available the next time you boot the system. If you're using the FTDISK service, however, you need to run the command slightly differently:
DISKPERF -YE
Using this command enables you to see the performance of individual drives combined into one logical drive.
There are, of course, other factors in the system that affect performance. These include network adapters, video cards, and software functions such as WINS servers and Domain Name System (DNS). Many of these functions can be monitored by using the Performance Monitor.
Each different protocol (TCP/IP, NetBEUI, and so on) has different performance characteristics. There are a number of reasons for this, including differences in the way the stacks for the protocol are implemented. So if you switch protocols, you might notice a difference in the performance of your network and server.
One of the more common components that gives network administrators performance problems is the election of browser masters. Browsing is the process used to find out what resources are available on the network. The browser master and backup browser masters are the systems that keep the lists of the available network resources.
The process that the systems on your network use to determine which system is the browser master is called an election. A somewhat complex set of rules determines how the election occurs. In certain circumstances, the election and the resulting network traffic can make your network quite slow.
For example, starting a server can force an election in certain cases. Depending on the outcome of the election, the computers in the network might need to get their information from a new browser master. This can generate quite a bit of network traffic, especially in a large network.
You can take steps to reduce the problems due to elections, as described in the following sections. You can also determine whether or not you have a problem by using the Browser object in the Performance Monitor. Counters are available that track announcements and election packets. So keep an eye on this data if you have unexplained slowness in your network.
One of the best ways to determine the source of a performance problem is to look at historical performance data, if you have it. The historical performance data can show you which resource became overused first. This can help you overcome a situation in which one performance problem masks another root performance problem.
The need for historical performance data is another argument in favor of data collection for capacity planning purposes. As I said earlier, you'd probably use summarized versions of the data for capacity planning. In most cases, however, I would only run the process to summarize the data once every couple of weeks or so. That way, I'd have the detailed performance data available.
If a performance problem crops up, you can then look back at the detailed performance data from a couple of weeks ago to determine the source of the problem. The symptoms of your system might look as though there's a memory utilization problem. The detailed performance data might show, for example, that processor utilization suddenly went up and was followed later by memory utilization.
TIP: Having the detailed performance data available for as long as you can afford to keep it can be a great aid in finding the cause of a performance problem. It's always a trade-off, though, between the disk space used by the data and how often that data proves useful. Consider moving the data to offline storage or a development system where disk utilization might be less of a problem so that you can keep the data for longer periods of time.
When there's a performance problem, you can respond in a number of different ways. Although upgrading the hardware seems obvious, in some cases there are other alternatives.
Going a route other than a hardware upgrade often requires an even greater investment of your time. For example, you might find that increasing the number of segments in your network solves some of your performance problems. Often though, making those kinds of changes to a network requires a great deal of work by the network specialists. You need to compare the costs of a hardware upgrade and how long that upgrade will solve the performance problems to the labor and other costs involved with possibly better solutions.
Upgrading hardware is an appropriate step for solving many performance problems. It's often such a seemingly easy solution that other options aren't even considered. Even the simplest of hardware upgrades, however, needs careful planning.
A poorly planned upgrade can cause a number of different problems. If you haven't selected the appropriate hardware, performance of your server could get even worse than it was before the upgrade. You also need to plan for any downtime involved in performing the upgrade.
I've heard of network administrators taking servers down, thinking there was nothing running on the server. Later the administrator finds out that a program was scheduled to run and didn't or ran at the wrong time because the system was down. Be careful not to approach an upgrade cavalierly.
Selecting Hardware for an Upgrade. It's possible to upgrade hardware and end up with a system performing worse than it did before the upgrade. For example, you might decide to switch from an ISA network adapter to a PCI adapter, thinking that performance will improve due to the faster bus speed of the PCI bus. However, after you install the card, you might find that the processor on the PCI card is not as fast as the processor on the ISA card, so you end up with worse network performance with the PCI card than with the ISA card.
Although the scenario just described might be rare, the point is that you need to compare all the factors that affect the performance of a given piece of hardware. Don't get stuck on the fact that one single aspect of a piece of hardware should make it faster than another piece of hardware. Compare processor speed and bus type, and take a detailed look at the overall specs for the hardware.
NOTE: The specs will often describe the estimated or measured throughput for a given piece of hardware. Although these numbers can vary depending on how the hardware will be used in your environment, they can be carefully used for comparing different hardware. I also encourage you to test the hardware thoroughly before you put it into a production server.
If you have a test or development server, put the hardware you're considering using into that server for a couple of weeks. Then use the Performance Monitor to evaluate what that hardware did to your system performance. Make sure that the server you use to test the hardware is as similar to the production server as possible.
Also try to make sure that the server on which you test the hardware doesn't already have other performance problems. If your test server has a processor utilization problem and you don't look carefully at the performance data, you might think that the network adapter performs well, when in reality the network adapter isn't being fully tested because the processor doesn't have time to route traffic to the network.
Talk to both the vendor of the hardware you're looking to upgrade and the vendor of your server. Be careful here because hardware vendors often have their own agenda. They want to sell you hardware, of course. However, you can use the information one vendor gives you as support when talking to another vendor.
Also make sure that when you're evaluating hardware for the upgrade that you check the Windows NT Hardware Compatibility List. Because the HCL is only updated from time to time, you can also check with the vendor to see whether the hardware has been certified for the HCL. You'll avoid many problems by sticking with hardware that's on the HCL or hardware that's been certified and will be on the HCL.
http://www.microsoft.com The most current HCL can be downloaded from Microsoft's Web site.
Planning for Downtime. I strongly suggest that you perform a number of preparatory tasks before you upgrade hardware, even if the upgrade seems extremely minor. One of the most important is communication with the potentially affected people, including offsite and Internet users. Even if you think that no one will notice, letting people know in advance of the upgrade will ease the situation if problems do arise.
Administrators often think that because they're upgrading the system at 2 A.M., no one will notice, so there's no reason to notify anyone. Even the simplest upgrade can result in unanticipated downtime, so users who know that there's an upgrade happening in the middle of the night will often be much more forgiving if they come in and find the system is still down. You also might be surprised to find that certain people dial-in in the middle of the night because performance is better then.
Make sure that you have all the software you need ahead of time. Midnight is not the time to find out that you don't have a driver that you need. Even if you can download it from a vendor's Internet site, this lack of planning can introduce complications. Make sure that you have the drivers, Windows NT CD, and any other software you need before you start.
Also have the correct Emergency Repair Disk for the system you're upgrading. That way, if you have a problem, you're in a better position to quickly get the system back up and running. I also recommend that you update the Emergency Repair Disk if you're doing anything that even remotely affects the software configuration of your system.
To update your Emergency Repair Disk or create one, run the RDISK.EXE program. You can see the Repair Disk Utility in Figure 39.8. Click the Update Repair Info to take that action. The program will let you know that you're going to replace the previous repair information. Click Create Repair Disk if you didn't create an Emergency Repair Disk when you installed Windows NT.
Use the Repair Disk Utility to update your Emergency Repair Disk after you're finished with a hardware upgrade or to create one before you start the upgrade process. It will help in the recovery process if you run into certain kinds of problems, as long as you can still boot the system.
Don't forget the importance of backing up the entire system, as well. The Emergency Repair Disk will help if you have certain problems. Other problems, however, can only be resolved by having a complete system backup.
Sometimes you'll be able to isolate the performance problem you have with your server to a specific software package. You might find, for example, that your relational database is running slowly. Although many people would jump on the problem and upgrade the hardware, consider contacting the software vendor first about the performance problem for a couple of reasons:
When the software vendor makes a fix that improves performance, the improvement often only shows in specific situations. However, new versions of software often incrementally improve performance, as well. Vendors often announce when there's a significant performance gain in a new version of their software. When you're confident about the stability of a new version of a software package you run, put that new version on as quickly as you can.
When your system is having a performance problem, make sure that you thoroughly review the configuration of your system. Often, you can make small changes to the configuration of your server and have significant improvements in performance. Consider at least two levels of configuration changes: the application software level and the server level.
The application software configuration means that there are, for many applications and utilities, settings that affect the performance of the software. Review the documentation for all your utilities and applications. The manuals might have sections that cover changes you can make to affect performance.
Many settings within Windows NT Server affect performance of the system as a whole. These settings can affect how well your system responds as a file server and as an application server.
Foreground and Background Application Priority. The first setting you should consider is how foreground and background applications are prioritized. You can configure this setting in the System Properties dialog box (accessed by clicking the System icon in Control Panel and then clicking the Performance tab). This dialog box is used to control the priority that the system gives to foreground and background applications. You can also get to the virtual memory settings from this dialog box.
Windows NT Server handles several performance intricacies on its own, but there are a number of places where you can influence how Windows NT Server performs--for example, the System Properties dialog box. This dialog box enables you to control whether Windows NT Server gives greater weight, in terms of processing, to foreground applications or gives all applications equal weight. There are three settings for the slider control: None, an intermediate value, and Maximum.
If you set the slider control to None, the system gives all applications equal weight in terms of the processor. If you set the slider to the intermediate setting, the system favors foreground applications but gives all applications access to the processor. If you set the slider control to Maximum, Windows NT Server's gives the best performance to foreground applications.
I normally have the slider control set to None. I'm a big believer that a server should only be a server. Users shouldn't be running applications directly from the server; the server should only be handling requests over the network. My concern is giving the sometimes hundreds of people who are using the server over the network the best performance possible. People who log on to the server itself shouldn't have a greater priority than network users, except in unusual situations. When you're trying to resolve a problem, though, you certainly want to give yourself enough priority to quickly get the problem resolved.
Virtual Memory Settings. The next configuration setting, which you access from this same dialog box, adjusts virtual memory. Click the Change button in the Virtual Memory frame to see and set virtual memory settings. You will see the dialog box shown in Figure 39.9.
The amount of virtual memory available can have a significant effect on performance. Use the guidelines shown in the dialog box to help you set the values that give the best performance for the hardware you have.
The paging file is used by the Virtual Memory Manager to store data for which there's not enough RAM. The larger the paging file, the larger virtual memory is. The size of the paging file is limited, though, based on the size of your hard drives and other factors. However, there's a range that the system will recommend, based on those factors.
You can see the recommended paging file range in Figure 39.9. This is shown in the Paging File Size for Selected Drive frame. The drives are listed in the list box at the top of the dialog box. By clicking the different drives, you can see how the paging file is set up for each drive.
In Figure 39.9, drive C: is selected. The initial size of the paging file is 32M, and the maximum size is 82M. You can change these values and store the changed values by using the Set button. If a drive has no paging file, the value is zero. The Total Paging File Size for All Drives frame shows the sum of the size of the paging files on all drives.
Server Memory Use Configuration. One more configuration setting affects the performance of your server as a whole; the server memory use setting affects the way memory is used on your server, as well.
To get to the Server dialog box, click the Network icon in Control Panel. In the Network dialog box that appears, click the Services tab. Choose Server Network Services, and click the Properties button. Doing so displays the dialog box shown in Figure 39.10.
Four settings relate to the type and size of network that you have. Three of the values are used in allocating memory based on the number of connections, and the fourth value is used in an application-sharing network. Table 39.2 explains how each of the values is used and affects the performance of your server.
The selection you make depends on whether you're running a small, medium-sized, or large file-sharing network or are using applications that do their own memory caching.
Table 39.2 Settings for the Way Windows NT Server Allocates
Memory
| Setting | Meaning |
| Minimize Memory Used | Used when you have less than 11 clients connecting to your server |
| Balance | Used to allocate memory for less than 65 connections |
| Maximize Throughput for File Sharing | Used to allocate memory for a large number o fclient connections |
| Maximize Throughput for Network Applications | Used when your server is an application server and the application does its own memory caching |
The first three values are used for caching. If your server is primarily a file server, use one of these three values. Maximize Throughput for Network Applications is used for applications that do their own caching. Use this value when your server is primarily an application server rather than a file server.
There are compromises in just about every solution to a performance problem. There's rarely just one way to solve a problem. One of the considerations in selecting a solution to a performance problem is how cost-effective that solution is.
For example, say that your server has a performance problem. You know that the main problem is that the processor isn't fast enough to handle the workload. There might be a number of different ways to solve this problem.
It's plausible that adding memory might help the performance of your system. If the Virtual Memory Manager needs to do less paging, that's less work the processor needs to do. So adding memory might help decrease the processor's workload. Let's say that adding 32M of memory costs $200 plus $25 for labor.
Another option is to put a faster processor in your server, if it's supported. You might have a 133MHz Intel Pentium in your server right now. You know that the motherboard supports up to a 200MHz Pentium processor. The next incremental jump in processor speed is a 150MHz or 166MHz processor.
Say that you can get the 166MHz processor for $400 plus $25 for labor. The memory upgrade is comparatively less expensive. The memory upgrade might only solve the problem for a couple of months, however, whereas the processor upgrade might solve the problem for a year. In that case, you'd upgrade the memory and then a couple of months later need to upgrade the processor, as well. So instead of spending $425 for the processor, you'd end up spending $650 for the processor and the memory.
On the other hand, you might know that the workload on your server isn't increasing. Maybe you're only running a DNS server on the system, and you know you're not going to add any more systems that you'll register with the DNS server. So the memory might be all that you need for another year.
You need to weigh all the practical options you have available in light of your environment. Sometimes the worst mistake is to hire a consultant to help you with a performance problem. A consultant doesn't live with your systems day in and day out and won't have the knowledge of your business that you do. A consultant might jump on the processor upgrade without realizing that the memory upgrade might be the more cost-effective solution.
You've determined that there's a performance problem, isolated what's causing the problem, and decided how to address the problem. The next step in solving a performance problem is to implement the solution you've selected. This is the step most fraught with danger. If you haven't adequately planned both how to perform the upgrade and what to do if there's a problem, it will pop up and bite you here.
You can take steps to make sure that the implementation phase goes as smoothly as possible. I've discussed having all the software resources you need available before you start. Some additional information will help the process, as well.
One of the most important warnings I can give you--whether you're upgrading hardware or changing the configuration to improve performance--is to change only one thing at a time. Although you might get away with not heeding this advice for a long time, sooner or later the problems associated with changing multiple factors will appear. There are several reasons to pay particularly close attention to this advice.
If you have a problem with your system after changing multiple factors, how will you know which caused the problem? You'll have to back out all changes, both in hardware and configuration, and then go through the process step-by-step. This is the only way you'll be able to isolate which change actually caused the problem and start the process of determining why it resulted in a problem.
What if you later want to know how to resolve a similar performance problem? Making a number of changes at the same time will hide the effect of each change on performance. Changing one item at a time, therefore, might make it easier to solve performance problems in the future.
Finally, changing one item at a time is simpler from a logistical perspective. If you're going to swap the network card with a faster one, add a second processor, and add memory, there's a lot you need to do to prepare for each change. If you take it one step at a time, each step is easier and therefore less prone to mistakes.
Testing any change I'm about to make on a non-production machine has saved my skin many times. There are several ways to gain from this kind of testing. Put them all together, and you have a compelling argument for getting a test machine, if you don't already.
Testing the upgrade or configuration change on a non-production system enables you to test the process itself. You can find out whether or not you have met all the prerequisites. You'll find out whether or not you have all the software and hardware that you need. You may also find out whether or not the change you're making is allowed in the first place. In some situations, combinations of configuration settings aren't allowed. You often can't find that out until you try to make the change and reboot the system.
Testing the change on a non-production system also enables you the opportunity to test what effect the change might have. Tools are available that enable you to test a system under a simulated load. For example, you can use the Response Probe tool from the Windows NT Server Resource Kit.
Remember that the trick is to use a system that's as close to your production system as possible. If your production server is a 200MHz Pentium system with SDRAM and PCI components, testing on a 66MHz 486 system with DRAM and ISA components might not be a good test. However, any testing is usually better than no testing at all.
If you're in a situation in which you need additional processor resources, one option is to add additional processors (of course, this depends on whether or not the motherboard supports them).
CAUTION: If you decide to add additional processors, I want to warn you that the process is not always as easy as just plugging in the additional processor and turning on the system.
Windows NT supports up to four processors out-of-the-box. Certain hardware vendors, such as Digital Equipment Corporation, support more processors, but they supply their own HAL. HAL is the part of the operating system that creates a certain level of isolation between the hardware and the operating system and programs.
Not only does your hardware need to support multiple processors, but in a sense the software does, as well. The issue is whether or not your software is multithreaded. If your software only uses a single thread, then you won't see much of an advantage to using more than one processor.
Threading is a concept in which a program divides what it needs to do into separate processing units. For example, a relational database might start a separate thread for each user of the database. That way, if a thread is off doing something for one user, another thread can be doing something for another user, if resources are available.
Most applications, as they should be, are multithreaded, but you need to find out before you start adding processors. The Performance Monitor has a Thread object to enable you to monitor threads, so that's one way to find out whether your application is multithreaded. You can also simply ask the software vendor.
If your system has one processor and you're ready to move to two processors, you must take an additional step. Namely, you need to change some operating system files. Here's a list of the files that need to be changed:
You can change these files manually, but there's a better way. Included with the Windows NT Resource Kit is a program named UPTOMP.EXE. It automates the process of copying the files needed to switch from a uniprocessor environment to a multiprocessor environment. So when you're ready to switch to multiple processors, make sure that you've done your homework.
After you've upgraded your hardware or made configuration changes to improve performance, there's one more step: You need to monitor your system to make sure that you're getting the performance improvement you needed and expected. You also want to make sure that other performance problems haven't popped up.
There's a concept called latent demand, which means that when you have a resource that is bottlenecked, the resource can hide other heavy demands on other resources. Latent demand manifests itself when you immediately begin having a performance problem with a resource shortly after you've upgraded another resource.
For example, suppose that you upgraded your memory because the page faulting rate was high. Now the page faulting rate is better, but the processor is suddenly overused. You might not have known this because the demand for processor resources was being limited by the bottleneck on the memory resources. But now that you have the memory resource problem resolved, suddenly you have a processor resource problem.
To track whether a performance-related change has had the desired effect, there is a series of steps you need to take, as described in the following sections. These steps help you understand what effect your change had on the performance of your server. They also help you be better prepared next time you run into a performance problem. You need to understand both the problem and what level of performance gain the solution will provide.
One important step in tracking what effect your hardware or configuration change has had is to keep representative data from before the change. It is hoped that you're keeping summary data for capacity planning purposes. However, you'll also benefit from keeping some of the detailed data from before the change.
I'm not suggesting that you keep large amounts of data. I suggest keeping detailed data from the month before your upgrade. That will help you identify the effect of the change on a wide variety of processing that your server does, yet not take a great deal of disk space.
The next step after the change is to collect performance data and compare that data with the data you collected from before the change. You need to go through the data at a detailed level to see the effect on every component. Sometimes the effect may surprise you. Components that you expected not to be affected may show a positive or negative performance change.
If you've upgraded the memory, for example, you might not expect a change in the performance of your network adapter. However, because of the latent demand, just such a situation might arise.
Possibly the most important step you can take after a performance change is to listen to your end users. Let them know what you did and what kind of change you expect them to see. Then ask them to let you know whether they see the change you're expecting.
The real trick here is to educate your end users. Let them know that a short-term problem doesn't mean that the change didn't work. End users may not understand that servers almost always have short-term bottlenecks. Everyone wants to get his or her work completed at certain times of the day; sometimes people start processes that they didn't intend to, and those processes tie up the server.
What you're trying to get from the end user is an overall impression of whether she's able to get her work done in a shorter period of time. IS people often get stuck in measuring whether the processor is 40 percent used or 60 percent used. The real question is whether users are able to get their work completed in a timely manner, not what the processor utilization is.
I'm now going to go through my top 10 Windows NT Server performance tips. Some of these tips apply to all servers, and some apply to servers running particular applications and services. I tried to mix them up so that anyone can find a tip that helps him improve the performance of his server.
When you store data on a non-striped drive, the hardware usually tries to keep all the data close together. It's usually faster for a drive to read adjacent data than to search around for data in random spots on the drive. However, when you delete data, holes of free space are created. Over time, it becomes more and more difficult for the drive to find large sections of adjacent free space to store your data. This is called fragmentation and can reduce the performance of your hard drive subsystem.
Most people familiar with PCs are familiar with fragmentation and the need to defragment a hard drive. Defragmentation means reorganizing the data on the drive so that like data is stored together as much as possible. Defragmenting a hard drive can significantly improve performance.
The problems associated with fragmentation on an NTFS volume are often less serious because of the structure of NTFS. Performance of the drive can drop when fragmentation becomes widespread on the drive. Tools are available that will defragment both FAT and NTFS volumes. When you acquire one of these tools, make sure that it's designed for NTFS and FAT. Microsoft has information on its Web site (http://www.microsoft.com) about defragmentation tools for NTFS.
Every service that you have running on your system takes a certain amount of processor and memory resources. Having services running that you don't need can affect the performance of your server. So review the services that you have active and make sure that only the services you need are running.
You can review the services that are running by using the Services tool in Control Panel. From Control Panel, double-click the Services icon. A window similar to the one in Figure 39.11 is shown, listing the services that you have installed. The window also shows which services are started and when others are scheduled to start.
You can also see which services are active using the NET START command. Using this command without any additional parameters lists the started services. This is a handy command because you only see active services.
The Services dialog box is used to review services. Services that are running have a status of Started.
You can have a page file used for virtual memory for every drive on your system. If you have multiple drives, having a page file for each drive can improve the performance of the Virtual Memory Manager. Review the settings for the page file from time to time even if you aren't adding drives.
To see and change the page file information, double-click the System icon in Control Panel, click the Performance tab, and then click the Change button. You'll see a dialog box similar to the one shown in Figure 39.12 that allows you to change the virtual memory settings.
In the Virtual Memory dialog box, you review and change virtual memory settings. If you add a drive, setting the page file information for that new drive can improve the performance of your server.
You can see in Figure 39.12 that I have a page file set up for drive C:. However, no page file information is set for drive D:. I can start the process by clicking the drive in the list box at the top of the window. Then I need to fill in the Initial Size and Maximum Size fields and click the Set button. Then I click OK, and I'm ready to reboot the system so that the change will take effect.
If I had a nickel for every system I've seen that had unused protocols loaded, I'd be rich beyond my wildest dreams. Just about every system I've ever worked on has had both NetBEUI and IPX/SPX loaded and running. When I ask the network administrator why, the answer usually is, "I don't know--they both loaded by default."
Every protocol has different performance characteristics and support within Windows NT and when connecting to other servers and clients. You need to pick which protocol(s) you want to run based on those kinds of criteria; however, if you don't need a protocol, don't load it.
Each protocol takes memory that could be better used elsewhere. With the number of systems I've seen that have had unnecessary protocols loaded, it's no wonder that so many sites need more memory. Be sure to review the protocols you're using and remove any that you don't absolutely need.
Sometimes I want a certain process to finish as quickly as possible so that I can continue with the next step. If that certain process runs at its default priority, it may not finish very quickly. So I can use the Task Manager to change the priority of a running process.
In Figure 39.13, you can see how to change the priority of a process. You need to start the Task Manager and click the Processes tab; then right-click the process you want to change. You can set the priority by choosing from Realtime, High, Normal, and Low. Normal is the priority at which this process is running.
The Task Manager can be used to change the priority of a process. If you aren't sure which process you want to change, you can also click the Applications tab, right-click an application, and choose Goto Process.
CAUTION: Be very careful when changing priorities. Only do so when you know ahead of time what the effect will be. Changing priorities can have a detrimental effect on the stability of your system. I advise only changing priorities during the setup of a server, not while it's being used in a production mode.
Client systems send messages on the network announcing that the computer is on the network. In a large and heavily loaded network, these messages can reduce the performance of your network. If you have a fairly stable network in terms of systems starting up and being shut down, you can decrease how many times each system announces itself.
The announce value in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\LanmanServer\Parameters Registry key defaults to 12 minutes. So client systems send announcement messages every 12 minutes. You can increase this value so messages aren't sent as often.
You need to make this change on all the clients before it will start having an effect. The only downside to this change is that systems that are shut down will appear on the browser list longer than they did before you made the change. If you can live with that, making this change will reduce your network traffic.
DNS zone transfers happen between primary and secondary DNS servers. Whenever there's a change to your primary DNS database, that information is copied to the secondary DNS server to keep the secondary database up-to-date. The transfer to a non-Microsoft DNS server can be a bit slow.
By default, the Microsoft DNS server, when sending data to a non-Microsoft DNS server, assumes that the secondary server cannot handle multiple resource records per message. However, many current versions of DNS servers can handle this compression of data. One way to determine whether your DNS server can handle multiple resource records per message is to find out whether it supports BIND version 4.9.4 or greater. If it does, you can configure the Microsoft DNS server to go ahead and send multiple records. You need to create a new Registry entry and restart the DNS server to allow this.
The Registry entry is in the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\DNS\Parameters. Check for the parameter BindSecondaries. If it doesn't exist, create it with a type of DWORD. If your secondary DNS servers support multiple records, set the value to 0. Otherwise, set the value to 1. After you restart the DNS server, your zone transfers should be quite a bit faster.
LMHOSTS is a file used to link the names of systems to their IP addresses. That way, people can refer to computers by name, not by IP address. It's not terribly common, but it's an alternative to WINS and DNS.
The file contains entries that relate the names of systems and IP addresses. Here's an example of the entries in the LMHOSTS file (this comes from an example file included with Windows NT):
102.54.94.97 rhino #PRE #DOM:networking #net group's DC 102.54.94.102 "appname \0x14" #special app server 102.54.94.123 popular #PRE #source server 102.54.94.117 localsrv #PRE #needed for the include
When the LMHOSTS file has a large number of entries, it takes longer to find an entry and therefore longer to connect to a system. Some people don't realize that because this isn't a database file, the lookup can't go right to the record you need. The lookup process has to read all records until it finds the one you're referring to.
To improve the performance of the connect process when you're using the LMHOSTS file, put the most often used entries near the top. It's common for people just to add an entry to the end of the file and not think about whether that system is used a great deal. Try to put the entries you'll use the most near the top and put the #PRE entries at the bottom.
If you have many users accessing your FTP server, you may have run into performance complaints. If the complaints revolve around the system not responding to commands instead of download time, I may have a solution for you. It involves increasing the number of threads used to respond to FTP requests.
Check the following Registry key:
There may not be an entry under the key MaxPoolThreads. If there isn't, the default number of threads is 10. If you want to try increasing the number, add the key as a DWORD type and then enter a number higher than 10.
You'll need to restart the FTP server for this value to take effect. Be careful what value you set this entry to. Don't just set it to 1,000, thinking more is better. Make sure the problem is that you have the processor resources available, but the threads being used for FTP are being blocked. If they are, slightly increasing this value can help the performance your FTP users have.
Because of the security built into the NTFS file system, many people use it exclusively. However, there's also a performance consideration. I'm not suggesting that you base your decision about which file system to use solely on performance, but it should be one factor in the equation.
FAT performs better than NTFS for small partitions. For example, on partitions smaller than about 1G, FAT often performs better. One exception to this is where there are many files. In that case, NTFS sometimes performs better.
One suggestion I've almost always followed is to create a 500M FAT partition that I use for storing the operating system and programs. Then I create other partitions using NTFS. Here are some of the benefits of following this plan:
© Copyright, Macmillan Computer Publishing. All rights reserved.