Many IIS websites will experience performance degradation under high w3wp CPU usage … often well before you hit 80% processor time!
(See our new High CPU usage in the IIS worker process guide for the full details, and then go to Diagnose w3wp CPU usage for how to fix it the right way.)
Utilizing 100% of the processor time is usually not a problem for simpler programs that perform a single CPU-intensive action like video encoding, compression, or file transfer.
Sadly, that is not the case for web applications.
(There are reasons for this, more on that in a second)
A typical IIS website can suffer big problems under load, including:
- 503/queue full outages
- High CPU hangs (when the website stops serving requests or requests are very slow)
- 2x or higher hosting costs (to try to maintain low CPU usage on each server, even when under peak load)
This can also be especially frustrating in the cloud, where you are paying per instance hour, and end up having to basically waste half of your total paid server time on underutilized instances.
Why does high w3wp.exe CPU utilization cause poor performance?
It’s easy to understand why performance may suffer under 100% server CPU utilization, but why would the application start to hang when the processor is not even fully utilized?
The reasons are many, but they boil down to what I like to call “inelastic application workloads”.
I recently wrote about the specific reasons – and how to fix them – in the High CPU usage in the IIS worker process guide. They include:
- Thread pool exhaustion. The thread pool cannot grow effectively under CPU load, causing request queueing and timeouts.
- Async task starvation. Async or parallel tasks cannot complete due to competition for the thread pool threads with incoming requests (that are basically doomed to time out for that same reason).
- IIS thread pool starvation. IIS runs out of threads to dequeue incoming requests, causing massive amounts of 503 as the application pool queue fills up.
- Timeouts and wasted processing. Processing requests that end up failing/timing out wastes available CPU bandwidth without useful results.
- Context switching, garbage collection, and lock contention overhead. These are some of the most common activities we see that sap the useful CPU bandwidth under load.
An inelastic application often experiences these bottlenecks under load, and that causes it to perform worse than it should theoretically perform if it could “stretch” under the load.
Making your IIS website elastic under high CPU usage
The good news is that you can find and fix these bottlenecks to make your app elastic, and unleash your application’s full potential under load.
That means sustained performance under heavy load, lower hosting costs, and much better scalability.
If you are using LeanSentry, it will automatically detect opportunities to fix these bottlenecks and tune the code that actually causes high CPU usage in production.
You can then use the diagnostic reports to optimize the right code.
(This is important, because when you are optimizing the code from LeanSentry CPU diagnostics, you are fixing what actually causes CPU overloads for your production traffic … as opposed to the code that shows up during performance testing).
Check out the step-by-step process in Diagnose w3wp.exe high CPU usage.