Performance of web applications hosted in IIS can be affected with by the worker process reaching or utilizing the CPU resources to maximum and shows 100% which caused the subsequent requests to pile up due to lack of resources. I planned to write this article as I too had similar problems on one of the projects on the production machine which hindered the users and we got to hear a lot of complaints of the application being down and slow.
The IIS worker process utilizing a lot of CPU resources can be because of various reason, we will investigate some of the top possibilities and how to troubleshoot the same.
Some of the common reasons which might cause the IIS worker process(w3pwp.exe) to utilize the maximum CPU resources w3pwp.exe are :
- Requests getting blocked or stuck in the asp.net pipeline
- High Error rates in the web application
- High Web Traffic
- Garbage collection
- Inefficient .net code
- Outdated or Issues with the application dependencies
I will cover only certain important points in above scenarios and dig deeper on point 1. To identify and analyse it
Requests getting blocked or stuck in the asp.net pipeline
First thing to do here is to look at the requests which are currently running and investigate whether they are stuck or hanged. This might give a brief idea on which requests are basically taking long time or getting stuck. There might be requests which are queued and not directly part of the problem or cause for alarm.
There are many steps in lifecycle of ASP.NET request. The basic steps include authentication, authorisation, evaluation of the http request, finishing the request. If facing any performance problems , the first place to start is identifying the specific Http module.
Open IIS management console, you can view the running worker process and select the IIS application pool in question which is causing high CPU and view current running requests
Select the worker processes from the IIS, you can see the currently running IIS worker processes.
Double click on the application pool name, it will take you to view all the currently executing requests. You can see that each request is in different parts of the ASP.NET pipeline and currently executing different HTTP modules.
The above snapshot gives you the below information for the currently executing requests.
- URL : the complete URL that is being executed
- Time: the total amount of time in milliseconds, the web request has been executing.
- Client : The IP address of the user that initiated the request
- State : the stage of the IIS pipeline that the request is currently running in.
- Module: the ASP.Net module that is currently executing.
To dig deeper the reason the actual issue what can be done is to obtain a memory dump from the w3wp.exe process like below: