Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why does IIS default to recycle the app pool after a given time? Is there some specific reason other than perhaps most web apps are not managing the memory prudently? Given that you are managing your application's memory properly, is is safe to go ahead and turn this off? What are some potential down sides, up benefits to turning off recycling or keeping it on?

share|improve this question
1  
are you sure you don't mean recycling the worker process, not the app pool itself? –  Ryathal Mar 28 '12 at 15:18
add comment

4 Answers

Yes, the reason it defaults to once a day is out of a worry that the web app could have a memory leak. The biggest downside to frequently recycling IIS app pools is that it will cause web.config reading, assembly loading, and a recompilation of asp.net pages and (if you don't believe in pre-compiling them) code behinds. This is a rather heavy process and it doesn't occur until the next request for a page after the app pool has recycled, greatly slowing down that particular request. IIS7 now has a module you can download called Application Warm Up to help "deal" with this issue.

I personally prefer to use memory-based maximums coupled with logging on app start rather than scheduling my recycling. This allows me to assume my app has no memory leak and be proven wrong when the app pool recycles.

share|improve this answer
    
+1, but it looks like they've taken down the application warm up module –  aceinthehole Mar 28 '12 at 17:24
    
what? That's hilarious. Maybe they'll figure out a better solution some day. :/ –  Randolpho Mar 28 '12 at 19:03
    
and now it looks like they ave released another –  aceinthehole May 3 '12 at 1:24
add comment

Feature is a holdover from classic ASP days when everything leaked memory and you had to do it. Most folks had a scheduled restart on the web server overnight. IIS6 automated this with app pool shutdowns every 1740 minutes (or if app is idle for 20 minutes). IIS7 continued the tradition.

Advice I got from microsoft back in those days was that this was unnecessary unless you had a legacy app with a known memory leak. So if you were running purely managed code you would be OK.

share|improve this answer
add comment

Shut it off and monitor the app pools. Most complex enterprise applications use lots of legacy code and much of that code is kinda leaky. So for most installs having the app pool restart occasionally is not a bad idea.

There are other options like monitoring the time of inactivity that may be a better solution for your situation.

Spinning up an app pool can take some time and make the application less responsive so keeping them up can help performance.

share|improve this answer
add comment

Indeed, this is purely to clean up leaked resources that (might) be present. The 1740 minutes is not the only triggering event either. It also happens after a specific maximum number of requests or after exceeding a specific amount of worker process memory. It is pretty well documented in the MSDN library. Unfortunately, this policy breaks things like session state and statics such as singletons. Your app will need to be robust enough to re-authenticate users and/or re-initialize singletons as needed to avoid disturbing your user's experience. It forced us to manage authenticated sessions in the database rather than in the ASP.NET session. Otherwise, our users were booted back to our login page whenever the server recycled due to one of these triggers.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.