Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When you setup a site on IIS it defaults the worker process to recycle every 1740 minutes (29 hours). Why an odd number like 29 hours and not, for example, 24 or 48 hours?

share|improve this question

migrated from stackoverflow.com Jan 10 '12 at 14:39

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers

up vote 23 down vote accepted

At Tech Ed 2003, the presenter was asked this question, and the answer was that they wanted an irregular cycle to prevent it from occurring on a daily boundary (e.g. to distinguish from other daily tasks scheduled on the server / domain).

The site here speculates:

... (29 is the) first prime after 24, allowing it to have the least chance occurring in a regular pattern with any other server process; easing the investigation into problems

share|improve this answer
    
Interesting. Personally I think that having something recur at the same time each day would make it easier to track if the worker process recycle was causing other issues. e.g. tracking down an issue that happens approximately every day is tough but it's easier if it happens at 7pm every day because you can search the system for events that happen at that time. I know that you can set IIS to recycle whenever you want or not at all but most leave it at its default. Thanks for the answer! –  Guy Jan 11 '12 at 6:20
add comment

OK, this was bugging me, so I dug around and finally found this posting from a guy who apparently was on the IIS team:

The reason that IIS6 recycles every 29 hours by default (and we had a reason

The reason that IIS6 recycles every 29 hours by default (and we had a reason for choosing 29 hours as the default value) is because more likely than not, the web application running on it is unreliable and literally needs to restart frequently.

Thus, IIS6 is built around the premise (admitedly cynical) that the user's web application will not run for more than 24 contiguous hours, features are planned accordingly, and defaults chosen. Worker processes recycle every 29 hours, process startup and shutdown are monitored, the process is constantly pinged to make sure it is running, the process handle is tracked and signaled when it terminates unexpectedly, etc etc.

Realizing that recycling is a normal part of operations, IIS6 also makes sure to isolate such recycling from the end user -- the end user's TCP connection never terminates during a recycle, due to some kernel-mode magic. Combined with user-mode application which stores session-state out-of-process (like ASP.Net Session State Service), one is virtually guaranteed reliable uptime with no user-visible data loss, even if the web application crashes after processing every single user request.

This is about as good as IIS6 can make it -- given an unreliable web application, make it appear reliable to the end-user, and do it without requiring any fixes of the unreliable web application.

Of course, not all unreliable application can be made to appear reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries a whole lot more to be resiliant.

In your case, it just happens that the resiliancy has a side effect on non-persisted user state, but it can be easily adjusted.

Assuming your web application never has a problem and stays with in- process session state, you will want to change these defaults: 1. Turn off the 29 hour periodic recycling 2. Turn off the 20 minute idle timeout

This will prevent unexpected loss of session state.

Of course, if you ever use an application with out-of-process session state, you can leave everything as the defaults and never notice a difference in functionality nor reliability.

share|improve this answer
1  
I feel dumb asking this but if IIS assumes the web app does not make it to 24 hrs, how come 29 was a good choice? Shouldn't they have picked a number below 24? Where am I wrong in interpreting this explanation? –  Alpha Jan 12 '12 at 23:33
    
Perhaps there is no "best" answer for the default value, and the person administering the website should make a deliberate decision based on the app and the system. –  DOK Jan 13 '12 at 14:09
    
@Alpha - I agree - that doesn't make sense - it should default to 22 or 23 hours or at least something lower than 24. –  Guy May 9 '12 at 5:15
    
[citation needed] –  piers7 Mar 11 '13 at 0:48
    
I'm getting a strange compile error on parts of the website every morning that can only be fixed with a recycle. My guess is the Idle Timeout triggers overnight due to low load, and for some reason, when it starts up again, the compile error is back. Thanks for the lead, I'll follow this path to fixing my issue... –  sonjz Jun 16 at 16:04
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.