Getting more out of IIS - part 1

27 Apr 2014

I recently attended a great talk on IIS at DevWeek 2014 by Ido Flatow, which discussed a number of the extended features available.

I’ve been using IIS in its various versions for many a year now, and it turns out there was a lot I was missing!

I’ll start with some advanced application pool settings - in a future post I’ll go over some other more general features of IIS itself. Note that all features mentioned here are found in IIS 8.0, although most can be found in earlier versions. Most are available in the default installation, whereas some need to be added specifically.

Advanced application pool settings

There are a few very handy things you can do with the advanced settings of an application pool to give you more control over the lifecycle and lifespan of each process, and the information generated by each one.

CPU throttling

This one’s pretty straightforward. Set the ceiling on how much processing power should be given over to a particular application pool, and IIS will attempt to ensure that pool doesn’t get too processor-hungry. It’s not an exact science - processes won’t be constrained to precise percentage values - but it could make a big difference to other working sites if one of your processes hangs or crashes.

There’s more to it than this though - have a look at CPU Throttling in IIS 8.

Recycling

Application pools are set to recycle every 29 hours by default. This is handy (and there’s a good reason for it), but you may still want more fine-grained control. You can override the default settings to: change the regular recycle time; recycle if the memory used by an application pool reaches a certain threshold, or configure IIS to log an event when application pools are recycled (for either expected or unexpected reasons).

Configuring Recycling Settings for an Application Pool

Process orphaning

This one’s pretty sweet. Normally process failures are unexpected - and when they happen, you usually don’t have much log information to fall back on, in order to diagnose the issue. You can use the default logs, but (a) they’re a pain in the eyes and (b) they don’t provide granularity to the individual application pool level. Process orphaning provides a means to generate some better diagnostic information about the failure.

When this feature is switched on, application pool processes that fail do not get destroyed or recycled, but instead get abandoned. A process in the abandoned state is cut out from IIS, but remains active so that you can take a look at it before it is terminated.

Even better - the settings also allow for a command to be defined that will be run when a process gets orphaned. For example, you could generate a dump file that you can debug in Visual Studio.

(There’s also the option of using advanced logging to give you a better view of the lead-up to the failure. But that’s for another post…)

Rapid fail protection

Another way that processes can often fail is on startup - say there’s a terminal configuration error in the website config, or simply that there’s no available CPU to run the process. If a process fails in this way, IIS will helpfully attempt to restart the failed process upon the next request. If the problem causing the failure is protracted, the worker process could get caught up in a repeated failure/restart loop.

Rapid fail protection is an option, enabled by default, which will watch for and deal with this kind of scenario.

When rapid fail protection kicks in, it will stop the process and any further requests made to the affected site will be met with an HTTP 503 (Service Unavailable) response.

By default, rapid fail protection will react if a process fails more than five times within a five minute period - but these settings can be altered. Also, as with the process orphaning option above, it’s possible to execute a command when rapid fail protection takes over (such as sending an email to a helpful sysadmin, for example).

End of part one

That’s it for this part. As usual, I have to say at this point that there’s a bunch of other advanced application pool options that I haven’t covered here.

In the follow-up I plan to look at some other rather lovely options around caching, compression, advanced logging and URL rewriting. Nice.