Scott Forsyth's Blog

Postings on IIS, ASP.NET, SQL Server, Webfarms and general system admin.

Cloud Resources

IIS Resources

Why is the IIS default app pool recycle set to 1740 minutes?

Microsoft IIS Server has what appears to be an odd default for the application pool recycle time. It defaults to 1740 minutes, which is exactly 29 hours. I’ve always been a bit curious where that default came from. If you’re like me, you may have wondered too.

Wonder no longer! While at the MVP Summit this year in Bellevue WA I had the privilege again of talking with the IIS team. Wade Hilmo was there too. Somehow in the conversation a discussion about IIS default settings came up, which included the odd 1740 minutes for the app pool recycle interval. Wade told the story of how the setting came into being, and he granted me permission to share.

As you can imagine, many decisions for the large set of products produced by Microsoft come about after a lot of deliberation and research. Others have a geeky and fun origin. This is one of the latter.

The 1740 story

image

Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.

Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!

That’s a fun little tidbit on the origin of the 1740. How about in your environment though? What is a good default?

Practical guidelines

First off, I think 29 hours is a good default. For a situation where you don’t know the environment, which is the case for a default setting, having a non-resonate pattern greater than one day is a good idea.

However, since you likely know your environment, it’s best to change this. I recommend setting to a fixed time like 4:00am if you’re on the East coast of the US, 1:00am on the West coast, or whatever seems to make sense for your audience when you have the least amount of traffic. Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools it may be wise to stagger them so that you don’t overload the server with a lot of simultaneous recycles.

Note that IIS overlaps the app pool when recycling so there usually isn’t any downtime during a recycle. However, in-memory information (session state, etc) is lost. See this video if you want to learn more about IIS overlapping app pools.

You may ask whether a fixed recycle is even needed. A daily recycle is just a band-aid to freshen IIS in case there is a slight memory leak or anything else that slowly creeps into the worker process. In theory you don’t need a daily recycle unless you have a known problem. I used to recommend that you turn it off completely if you don’t need it. However, I’m leaning more today towards setting it to recycle once per day at an off-peak time as a proactive measure.

My reason is that, first, your site should be able to survive a recycle without too much impact, so recycling daily shouldn’t be a concern. Secondly, I’ve found that even well behaving app pools can eventually have something sneak in over time that impacts the app pool. I’ve seen issues from traffic patterns that cause excessive caching or something odd in the application, and I’ve seen the very rare IIS bug (rare indeed!) that isn’t a problem if recycled daily. Is it a band-aid? Possibly, but if a daily recycle keeps a non-critical issue from bubbling to the top then I believe that it’s a good proactive measure to save a lot of troubleshooting effort on something that probably isn’t important to troubleshoot. However, if you think you have a real issue that is being suppressed by recycling then, by all means, turn off the auto-recycling so that you can track down and resolve your issue. There’s no black and white answer. Only you can make the best decision for your environment.

Idle Time-out

While on the topic of app pool defaults, there is one more that you should change with every new server deployment. The Idle Time-out should be set to 0 unless you are doing bulk hosting where you want to keep the memory footprint per site as low as possible.

image

If you have a just a few sites on your server and you want them to always load fast then set this to zero. Otherwise, when you have 20 minutes without any traffic then the app pool will terminate so that it can start up again on the next visit. The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. That can take a few seconds. Therefore I set that to 0 every chance I have, unless it’s for a server that hosts a lot of sites that don’t always need to be running.

There are other settings that can be reviewed for each environment but the two aforementioned settings are the two that should be changed almost every time.

Hopefully you enjoyed knowing about the 29 hour default as much as I did, even if just for fun. Happy IISing.

Comments

Leniel Macaferi said:

Scott,

Great reading! :)

Setting the idle time out to 0 was something I learned the hard way. hehehe

Best,

Leniel

# April 6, 2013 8:57 PM

Paul Lynch said:

Thanks Scott - I had always wondered about that odd 29 hours and now it does make sense.... :-)

Paul

# April 15, 2013 4:59 AM

Kevin Rice said:

First time I saw '29 hours' I immediately recognized it as prime and intuitively knew the reason. Perhaps, it should be 29 hours, 17 minutes? Good tip on idle time-out.

# April 29, 2013 2:35 PM

OWScott said:

@Kevin Rice, you have a good intuition then. I like the 29/17, or even 29+7 minutes which is 1447; the first prime number (from the minutes perspective) after 1440. There are a few fun options to choose from.

# April 29, 2013 8:19 PM

Bill said:

How does the app pool behave if you have both the default app pool to recycle every 1740 minutes and a specific time of day daily?

# May 15, 2013 12:45 AM

OWScott said:

Hi Bill,

The 1740 is a time since the last recycle, so the daily recycle would occur before 1740 could occur, essentially causing the 1740 to not be used.

The time interval setting could be used with the daily recycle if it's less than 24 hours (e.g. 4hrs). I can't think of many reasons to do so, but it's possible.

# May 15, 2013 9:21 PM

G Dhillon said:

Once again Thanks Scott :-)

# June 12, 2013 8:06 PM

Anicet said:

Hi Scott,

for some reason the App pool is recycling itself thus killing my Session variables. What could be causing the App pool to recycle by itself? And is there any tool you may know that I may use to monitor the App pool behavior?

Thanks.

# June 18, 2013 1:41 PM

OWScott said:

Hi Anicet,

This can be caused by recycling the application pool, or recycling the app domain. You can tell if the application pool has been recycled by watching the PID in task manager (add the PID column) and seeing if the PID changes. If the recycle is at the appdomain level then it's more work figuring out the cause.

There are a few things that can cause like, like an unhealthy page that causes the app pool to fail, app pool limits being reached (like memory or time), or simply creating folders on disk or making changes to web.config (these will cause appdomain recycles).

In IIS7+ you can edit the "Recycling..." feature for the application pool and in the 2nd step of the wizard you can turn on all Runtime recycling events. Then after the next recycle you should see a log of it in Event Viewer. There's no real drawback to doing this except some more chatter in Event Viewer (usually very minimal). If you lose session state but the PID doesn't change on the app pool then it's an appdomain recycle instead.

I've written a couple blog posts that explain this further:

weblogs.asp.net/.../application-vs-appdomain.aspx

weblogs.asp.net/.../ASP.NET-v2.0-_2D00_-AppDomain-recycles_2C00_-more-common-than-before.aspx

# July 19, 2013 5:49 PM

Ash said:

Hi Scott,

My application is developed in 1.1 framework and also we use SSRS integrated with the application where a chart is opened. This chart part is developed using 2.0 framework. Our application also uses SVN functionality maintained in a different server.Users are authenticated in code level to access the respective SVN path. We have configured App pool to make both the frameworks work. But since then none of the SVN functionality is working. Is there any other setting to be made in this particular scenario. please suggest.

# August 7, 2013 9:01 AM

OWScott said:

Hi Ash,

Each app pool can only work with 1 version of the framework at a time. Do you mean that you have two different app pools running the v1.1 and 2.0 parts of the site?

It's hard to know from the quick overview but first I would make sure that both parts of the site work by themselves. i.e. do they load, etc.

There are a few other considerations like inheritance if one part of the site is a subfolder of the other, etc.

What error do you get when the SVN part fails?

# August 8, 2013 11:54 PM

Max said:

Hi Scott,

Is there anyway to have an application pool recycle without users losing their work? Or is this unavoidable?

Thanks!

# September 27, 2013 1:24 PM

OWScott said:

Hi Max,

The solution for that is to store all critical memory out of process. For session state-the most common offender-use SqlState, AppFabric, another session state solution, or store everything in the database and use a cookie simply to authenticate and tell who the user is.

This way if an application pool recycles, or if you're in a web farm and move to another server, nothing is lost because all servers are completely stateless.

# September 30, 2013 12:25 PM

Bill said:

Hey Scott,

My server is running IIS 7. Occasionally I see System.Web.UI.ViewStateException: Invalid viewstate and my theory is that this is caused by the application pool recycling. I've read about using a fixed machine key to get around this, but I'm not sure if this solution works for IIS 7, and how to implement it.

# October 16, 2013 7:56 PM

OWScott said:

Hi Bill,

Yes, it is possible for app pool recycles to change the machineKey and throw off ViewState.

The easiest way to set this up is to use IIS Manager and go to the site and "Machine Key". Uncheck the two "Automatically generate at runtime" checkboxes and then click "Generate Keys". Click Apply and it will add what you need to your web.config file. Make sure to update your source code if needed.

# October 21, 2013 1:37 PM

Maruti said:

Hi Scott,

I donno if the question is related to this topic, please help me if you can.

I have .net 5 application and after deploying in it production, whenever I click any link that page is taking too much time to load.

I tried changing debug=false in web.config and we did app pool recycle but nothing worked.

I didn't check IIS setting you were talking about?could this be a reason for my problem???

My email: manamaruti@gmail.com

Thanks in advance!!

# December 10, 2013 10:21 AM

iis 7.0 said:

Hi Frds,

Recently I am facing a problem with website after publish. When I click on page header menu item then it is moving to that page and when I click on cancel button on that page again moving to previous page. If I repeat it 11 times, the response was lost and website was unable to response. At that time ,No one can't acess and perform any operations on it until I restart the Asp.net V4 classic application pool.

# February 3, 2014 10:04 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)