Nov 23, 2011

What should I do to make sure that IIS does not recycle my application?


I have a WCF service app hosted in IIS. On startup, it goes and fetches a really expensive (in terms of time and cpu) resource to use as local cache.

Unfortunately, IIS seems to recycle the process on a fairly regular basis. So I am trying to change the settings on the Application Pool to make sure that IIS does not recycle the application. So far, I’ve change the following:

  • Limit Interval under CPU from 5 to 0.
  • Idle Time-out under Process Model from 20 to 0.
  • Regular Time Interval under Recycling from 1740 to 0.

Will this be enough? And I have specific questions about the items I changed:

  1. What specifically does Limit Interval setting under CPU mean? Does it mean that if a certain CPU usage is exceeded, the application pool will be recycled?
  2. What exactly does “recycled” mean? Is the application completely torn down and started up again?
  3. What is the difference between “Worker Process shutdown” and “Application Pool recycling”? The documentation for the Idle Time-out under Process Model talks about shutting down the worker process. While the docs for Regular Time Interval under Recycling talk about application pool recycling. I don’t quite grok the difference between the two. I thought the w3wp.exe is the worker process which runs the application pool. Can someone explain the difference to the application between the two?

The reason for having IIS7 and IIS7.5 tags is because the app will run in both and hope the answers are the same between the versions.

Image for reference: enter image description here



Recycling is usually where IIS starts up a new process as a container for your application, and then gives the old one up to ShutdownTimeLimit to go away of its own volition before it’s killed.

It is destructive, in that the original process and all its state information are discarded.

But it is by default overlapped, meaning the duration of an outage is minimized.

To your question: all the settings on that page control recycling in some way. “Shutdown” might be described as “proactive recycling” – where the process itself decides it’s time to go, and exits in an orderly manner.

Reactive recycling is where WAS detects a problem and shoots the process (after establishing a suitable replacement W3WP).

Now, here’s some stuff that can cause recycling of one form or another:

  • an ISAPI deciding it’s unhealthy
  • any module crashing
  • idle timeout
  • cpu limiting
  • adjusting app pool properties
    • as your mum may have screamed at one point: “Stop picking at it, or it’ll never get better!”
  • “ping” failure * not actually pinging per se, cos it uses a named pipe – more “life detection”
  • all of the settings in the screenshot above

What To Do:


  • Disable Idle timeouts. 20 minutes of inactivity = boom! New process on the next incoming request. Set that to zero.

  • Disable Regular time interval – the 29 hour default has been described as “insane”, “annoying” and “clever” by various parties. Actually, only two of those are true.

  • Turn on DisallowRotationOnConfigChange (above, Disable Reycling for configuration changes) if you just can’t stop playing with it – this allows you to change any app pool setting without it instantly signaling to the worker processes that it needs to be killed.

That’s enough to cause a well-behaved process to live forever. If it dies, sure, it’ll be replaced. If it hangs, pinging should pick that up and a new one should start within 2 minutes (worst-case: ping frequency + ping timeout + startup time limit).

CPU limiting isn’t normally interesting, because by default it’s turned off, and it’s also configured to do nothing anyway; if it were configured to kill the process, sure, that’d be a recycling trigger. Leave it off.

But… then we get into .Net land, and AppDomain recycling, which can also cause a loss of state.

You do that by touching a web.config file in your content folder (again with the picking!), or by creating a folder in that folder, and that’s about as destructive as an App Pool recycle, minus the native-code startup costs (it’s purely a managed code concept, so only managed code stuff happens here). Antivirus can also trigger this as it scans web.config files, causing a change notification, causing….

Related posts:

  1. CPU Limits for Application Pools in IIS 7.5
  2. IIS Application Pool recycle after appsettings.config change
  3. IIS7: How to handle application pools which uses too much memory or CPU?
  4. Server Application Unavailable after upgrade to .NET 4.0 and MVC 3. AppPool Recycle fixes it
  5. Can IIS Automatic Recycle fail or timeout?

Leave a comment