CPU Limits for Application Pools in IIS 7.5

I see that in iis 7.5 I can set a CPU % utilization limit for a specified amount of time for an application pool. I can have also have it kill the worker process if this limit is violated. If tell it to do this, will the worker process automatically restart after it is killed, or is manual intervention required?

Over at Stack Overflow there is the mention that it can restarted at the completion of the interval...

Solution 1:

This looks like one of those cases where simulation (or source code access...>sigh<) is probably going to be the only way to see what the behaviour is with any degree of confidence.

The documentation for the event log entry for CPU quota recycling talks about recycling as follows:

By default, application pool recycling is overlapped, which means that the worker process that is to be shut down is kept running until after a new worker process is started. After a new worker process starts, new requests are passed to it. The old worker process shuts down after it finishes processing its existing requests, or after a configured time-out, whichever comes first. This way of recycling ensures uninterrupted service to clients. However, if an application in the application pool cannot run more than one instance of itself at a time, overlapping rotation can be disabled.

It would seem to me that, by definition, terminating a worker process because of excessive CPU consumption would mean that pending requests wouldn't be allowed to be completed (since they're exhausting the CPU quota).

To speak to your major concern: I'm not seeing anything that leads me to believe that a new worker process wouldn't be spun up automatically. The statement in your Stack Overflow link does make me question if the algorithm used by IIS may, in fact, tie recycling to the resolution of the timer used to measure CPU quota exhaustion. The best way I know to determine that would be to write a CPU-wasteful server-side component, deploy it into a test environment, and see how its recycling behavior acts. A simple component that sits in a tight loop for a few seconds and then returns a known string, combined with a client running a test harness with something like a pool of parallel "wget" processes might be enough. Hammer on it with a bunch of parallel requests from a client and report on how may requests receive the proper response versus error messages, etc. (It makes me feel so silly to have to resort to things like this as opposed to just going to look at the source code...)

Solution 2:

Given the comments in the other response, I've done my own testing, which I'll replicate here.

In my testing, limiting an application pool (v4.0 Integrated) to a small CPU limit (0.01%) and a small interval (1 minute) with the KillW3WP action enabled, going over this limit kills the w3wp by stopping the application pool.

After the interval limit is reached, the application pool is automatically restarted.

Changing the action to No Action does not alter the w3wp process.

In both cases, a System Event 5025 is logged.