| Previous | Table of Contents | Next |
One of the most useful methodologies you can use to determine how well your server is performing is to build a performance database. A performance database is a collection of raw data that describes the operation of a system-specific component. You might collect your data from observations you make while using the server. For example, you might notice that while administering the server locally, the screen redraws slowly during specific times of the day. By keeping track of these times, you might come to the conclusion that your server is more heavily used during these periods. You might even write off this observation as peak activity behavior. And, you might be right! Then again, you might be wrong.
The problem with performance data collected from your own observations is that the data could be tainted by your lack of objectivity. You might be in a hurry to accomplish a task. Normally, when any of us is in a hurry to accomplish a task, nothing seems to operate as fast as we expect. Therefore, everything seems to take longer than it really does. Of course, you could use a stopwatch to verify the time it takes to accomplish the task. At least this would give you a more realistic view of the passage of time. A better method, however, is to collect data over a long period of time to determine the overall behavior of your server.
One of the best tools you can use is the Performance Monitor. Not only can you capture vast amounts of data in realtime, you can export the data in either a tab-separated values (TSV) or comma-separated values (CSV) file format. Both formats are widely used and can be imported into database applications (such as Microsoft SQL Server and Microsoft Access) or spreadsheet applications (such as Microsoft Excel). Using a database or spreadsheet application, you can compare the data collected over a period of time to determine genuine peak periods of activity on your server. You can also use this performance data to spot a slow evolving performance degradation that might occur over a period of weeks or even months of constant server usage.
TIP: Another tool for building a performance database is a simple network management protocol (SNMP) tool specifically designed to manage your network. Hewlett Packard’s OvenView is one such application. This type of tool can configure various Windows NT services using the SNMP interface, monitor events in realtime, and warn you of potential problems. It can also be used to collect information for reports to summarize network activity, possible bottlenecks, and other performance-related data.
Of course, in order to build a performance database that you can use in this fashion, you need to create a performance template. This performance template can be used on each system you want to monitor. You can then use the data collected from each server to compare the performance of each server against each other. You can determine if one server is more heavily loaded and balance your network activity by moving clients from one server to another. Or, you can use the data to determine which server on your network needs additional resources (memory, disk space, and so on) to handle the heavier loads placed on it by your clients. The first step in this process is to develop a performance template that captures the desired information In the next section, you will learn how to accomplish this task using the Performance Monitor.
A performance template must be designed to capture the same object counters for each type of performance data. For example, you can create templates designed to capture the big picture. These templates could capture data to determine the processor, disk, and network utilization. This would give you a quick glimpse into the inner workings of your server without bogging you down with low-level performance criteria. You could use such a template to compare the overall performance of several servers on your network.
To determine how well your server is doing its job of resource sharing, you could have another template that collects the nitty-gritty details of the Server service. This template might capture counters for the number of logons, server sessions, open files, and other related items. Or, perhaps, you’re more interested in possible Server service failure items. These items might include nonpaged pool failures, paged pool failures, and work item shortages. All of these error conditions can be used to determine if your server could benefit from adding additional memory or possibly tuning your memory resources a bit differently. But, with so many object counters to choose from, how do you know which object counters to use? And how do you go about creating the performance template in the first place?
The first step in creating a performance template is to make a Performance Monitor chart so you can see—in realtime—if the object counters you are viewing will be useful for long-term collection. Then, you can create the Performance Monitor log to actually capture the data. After that, you can run the Performance Monitor at specified times manually to capture data, or you can use the Windows NT Scheduler service to automatically run the Performance Monitor with selected templates at specified times. For example, you could use the command shown in Listing 5.1 to run the Performance Monitor at 10:00 AM every day and load the TEST.PMW workspace file.
Listing 5.1 Scheduling the Performance Monitor service to automatically load a workspace file and run at a scheduled time.
AT 10:00 /EVERY:Su, M, T, W, Th, F, S /interactive %SystemRoot%\System32\PerfMon.EXE Test.PMW
| Previous | Table of Contents | Next |