Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do you keep the counter ON during heavy production loads
Which performance counters do you find useful for ASP.Net/IIS 6.0 websites?

share|improve this question
up vote 26 down vote accepted

I've never had problems running performance counters on my servers.

Microsoft suggests watching following counters for IIS:

  • Memory\Pages/sec
  • Memory\Available Bytes
  • Memory\Committed Bytes
  • Memory\Pool Nonpaged Bytes
  • Processor\% Processor Time
  • Processor\Interrupts/sec
  • Processor\System Processor Queue Length
  • LogicalDisk\% Disk Time
  • PhysicalDisk\% Disk Time
  • LogicalDisk\Avg. Disk Queue Length
  • PhysicalDisk\Avg. Disk Queue Length
  • LogicalDisk\Avg. Disk Bytes/Transfer
  • PhysicalDisk\Avg. Disk Bytes/Transfer
  • System\Context Switches/sec
  • Web Service\Bytes Total/sec
  • Web Service\Total Method Requests/sec
  • Web Service\Current Connections
  • Web Service Cache\File Cache Hits %
  • Web Service Cache\Kernel:URI Cache Misses
  • Web Service Cache\Kernel:URI Cache Hits %

Specifically for ASP.NET I would watch

  • ASP.NET\Application Restarts
  • ASP.NET\Requests Queued
  • ASP.NET\Worker Process Restarts
  • ASP.NET Applications\Errors Total
  • ASP.NET Applications\Requests/Sec
  • ASP.NET Applications\Pipeline Instance Count
  • .NET CLR Exceptions# of Exceps Thrown
share|improve this answer
@splattne: Thanks this is useful. Would give you +1 (but not able to yet). – Kb. Jun 5 '09 at 17:05
We are running stresstest and find that Requests Queued are slightly below requests current, and with 100 concurrent users requests current are around 110 and request queued on about 99. Single CPU server. – Kb. Jun 5 '09 at 17:23
Suggestion is: Add CPU. Agree? – Kb. Jun 5 '09 at 17:23
@splatne: +1 (as promised) – Kb. Jun 27 '09 at 14:34
@Kb: thank you! – splattne Jun 27 '09 at 15:11

As a general rule you should be gathering performance data all the time. That way you'll have all the data you need when you walk into your manager's office and say "Our peak load has been increasing by X% every week for the last few months, and at that rate we'll exceed our current capacity in about 3 months. We need to start planning for that now."

share|improve this answer

Though a late answer, I am sharing here what we had done with production environment.
Scenario was we had to find out the number of request hits on our web server and how many are served/is there any thread starvation/resource bottleneck occurring or not.
For that we used following counters with perfmon.exe

Counter:- Asp.Net Apps V2.0.50727.
Instance:- LM_W3SVC_1_ROOT_"HostedWebSite"
1). Requests Total :- Provides total number of requests from last IIS restart.
2). Requests In Application Queue
3). Requests Succeeded
4). Requests Failed
3). Requests TimedOut
4). Requests Rejected: Number Of rejected requests due to application request queue was full
5). Requests Not Found: The number of requests for resources that were not found.
6). Requests Not Authorized: Number of requests failed due to unauthorized access.

Counter:- .Net CLR Data.
1). Sql Client: Current# pooled and nonpooled connections:- Provides current number of connections, pooled or not.

Counter:- .Net CLR LocksAndThreads.
1). # Of Logical Threads
2). # Of Physical Threads

Counter:- HTTP Service Request Queues
1). CurrentQueueSize:- Number of requests in the queue
2). RejectedRequests: Total number of requests rejected from the queue

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.