Why does the IIS worker process recycle every 29 hours and not every 24 hours?
Solution 1:
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(Link dead) speculated:
... (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
Another site appears to confirm this :
(Wade Hilmo) 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
Solution 2:
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.