Monitoring and Tuning Your Server

Examining the Results

If you find problems, you can use these and other counters to analyze them. For example, if you see evidence of a memory leak (a slow rise in committed bytes or pool nonpaged bytes), you should monitor processes. Similarly, if you see evidence of a disk bottleneck, you can examine reads and writes separately as you begin to track down the problem.

Note When interpreting the counters, remember that they show the most recently observed value, not a long-term average, unless they specify otherwise. You can use the log mode in PerfMon to determine the average values.

If you support a SQL database, be sure that your SQL Server Objects report events to Windows 2000 Server if the objects suffer errors. If, for example, your server runs 10 threads, and all of those threads become involved in SQL Server Objects that hang, ASP processing comes to a complete halt until you stop and restart the server. You can examine the event log and the Connection Attempts/ sec counters to detect this condition.

Internet Information Services Global\ Cache Hits % should be high because otherwise you are thrashing your server’s disk. On the other hand, when you first start your Web server this number is going to be low until the cache has actually been populated with files. If you see a low number a few minutes after you bring up the server, you can ignore it. If the number is still low after you’ve had thousands of hits, something is probably wrong unless (for example) you are maintaining a large database on your server, and you have users performing a wide variety of unrelated queries. If very few pieces of information are requested more than once, the number of cache hits is going to be small; there isn’t much you can do about it unless you can afford enough RAM to put the entire database in memory. This, at least, will provide a considerable decrease in access time on the database server.