One regular question posed to our team deals with the performance counters set-up to ensure IIS and ASP.Net application(s) are working properly. However, as every web-application and hence every IIS Server, will behave differently depending on what will be executed, obviously the threshold for which performance will be impacted will vary a lot. Thus, it's essential to define those key values before putting your application in production. By doing a progressive load test, you should be able to identify when the application performance is degraded. Once you've determined the threshold limit before degradation and the threshold where everything is working well, you just must collect the performance counters and you'll get your key values.
Now you know how to define your key values, you need to know how to collect them. To do so, you could use the excellent PAL tool (https://pal.codeplex.com/) which gives a predefined list of counters to monitor based on the selected product. By using those scripts, you should be able to get a good overview of your application and IIS behavior under load.
However, it could be interesting to broaden the scope to get key values in order to have a global vision of how the whole server is behaving instead of just IIS or ASP.NET. You need to check CPU, Memory, etc and put this in balance with your application and IIS.
Here is a non-exhaustive list of counters you could use to get this vision:
For IIS:
Memory:
- Available Mbytes: Allows you to see the available memory. It's important to be sure the server isn't undersized for the needs of the application
- % Commited Bytes In Use: Allows you to see the used memory. It's interesting to put this in balance with the Available Mbytes counter
Process (For all W3WP.exe processes):
- % Processor Time: Allows you to see the CPU consumption for a given process
- Virtual Bytes: Allows you to see the virtual memory for the process W3WP.exe
- Private bytes: Allows you to see the private memory for the process W3WP.exe
Processor (All instances):
- % Processor Time: Allows you to put in balance the total CPU consumption with each W3WP.exe. For example, if your server is consuming 90% of CPU and the sum of the W3WP.exe CPU consumption is 10%, you clearly have an issue elsewhere than IIS
HTTP Service Request Queues (All instances):
- CurrentQueueSize: Allows you to see the size if the HTTP Kernel side queue and thus to see if a huge number of requests are getting queued without being handled by the User Mode side
- RejectedRequests: Allows you to see if requests are rejected from Kernel side without being handled by the User Mode side
APP_POOL_WAS (For all listed Application Pools):
- Current Application Pool State: Allows you to see the state of an Application Pool
- Current Application Pool Uptime: Allows you to see if the Application has been restarted or not (relay useful during a load test)
For ASP.NET:
ASP.NET Applications (For all applications you want to monitor):
- Compilations Total: Allows you to see the number of compiled pages
- Request Bytes In Total: Allows you to see the number of received bytes
- Request Bytes Out Total: Allows you to see the number of sent bytes
- Request Execution Time: Allows you to see the execution time for the most recent request
- Request Wait Time: Allows you to see the time spent in the queue before being handled for the most recent request
- Requests Executing: Allows you to see the number of requests being executed
- Request in Application Queue: Allows you to see the number of requests in the queue
- Requests Timed Out: Allows you to see the number of timed-out requests
- Requests/Sec: Allows you to see the number of requests executed per seconds
- Sessions Active: Allows you to see the number of active sessions
ASP.NET V4.0.30319:
- Application Restarts: Allows you to see the number of restarts for the Application Domain
With all this information, you should be able to determine the threshold where your application is behaving as expected and the threshold where problems should start to occur. In addition, if you want to go further on ASP.NET, you could have a look to this old but good article which explains some key counters and how to detect some known issues: http://linqto.me/perfaspnet
I hope this article has been useful.
originally written by: Sylvain Lecerf
reviewed by: Muna AlHasan
