IIS Performance Monitor Questions

[TravisLaborde]

I've begun to have problems with my ASP site, and I'm looking into the Performance Monitor on the IIS box. It is running on Windows 2000 Server. It is a bit confusing, and I have a few questions. If anyone can help I'd greatly appreciate it:

1) % Processor Time: I'm assuming this is a measure of how much the CPU is taxed from moment to moment... I see that it spikes up to 100% often, and near 100% quite often. Is this normal, or bad? My ASP pages should be doing very little computation, other than cycling through ADO Recordset objects to generate tables and forms from a database.

2) Requests Queued: Someone told me this should always be 0. Is that right? Mine sits at 0 for a while, then slowly climbs up to around 20, then shoots back down to 0 all at once, and repeats. Any ideas?

3) Is there a good article or book that explains all of this, in plain English?

It is reporting 0 Errors per second, the Request Execution Time is at 0 mostly, spiking up every now and again, but not at the same time the CPU is spiking, and not causing other counters to spike either. It just doesn't make sense to me.

Thanks,
Travis

 

[Webwench]

1. 100% CPU is bad. If traffic isn't causing this load, then it might be the ASP code. Maybe an unintentional loop?

2. If you're using the defaults for server 2000, you can have up to 25 concurrent ASP's per processor. I think this performance counter should normally fluctuate, but remain within the lower 1/2 of the range for your server.

3. Check Microsoft's tech site (

http://www.microsoft.com/technet)

for subjects like: "server 2000 performance", "web server tuning", or the specific counters you're interested in "asp requests queued".

Here's the most effective way I have found for using performance monitor:
1. Define a list of potential causes for the problem you're experiencing. Searching technet helps.

2. Running perfmon from a different computer, ceate perfmon logs of lots of related counters: asp, web, system, processor, process. Have lots of space for the log files. If the problem occures over a period of time, only collect the counters evey 2 minutes - so the log files don't get so large.

3. While you're collecting that data, do more research on the counters. Find articles that list the significate counters for each potential cause.

4. When the problem occurs, stop the log. Get your server working again, and then restart the log. (It will make a separate file for each logging session). Also check Event Viewer to see if the same entries occur for every failure.

5. You can then open these historical logs into perfmon to look at what happened right before each failure. Load counters based on your research.

6. When all else fails: load about 30 counters at a time, and look for pattern changes previous to failure. Be prepared that you may find a trend, but still won't know what causes it to happen. That's when all those articles and research may help out.

Good luck