当你在IIS上设置一个站点时，它默认工作进程每1740分钟（29小时）重新启动。 为什么像29小时这样的奇数，而不是24或48小时？
在Tech Ed 2003上，主持人被问到了这个问题，答案是他们想要一个不规则的周期来防止它在每天的边界上发生（例如与服务器/域中的其他日常任务相区别）。
这里的网站（链接死了）推测：
…（29是24之后的第一个素数），使其与其他服务器进程的规则模式发生的机会最小; 缓解对问题的调查
另一个网站似乎证实了这一点：
（ 韦德Hilmo ）build议29小时，原因很简单，它是24 岁以上的最小素数。他想要一个交错和不重复的模式，每天不会发生一次
好吧，这让我烦恼，于是我挖了一遍，终于从一个显然是在IIS团队中的人那里发现了这个post ：
IIS6默认每29小时回收一次（我们有一个原因
IIS6默认每29小时回收一次（我们有理由select29小时作为默认值）是因为更有可能的是，运行在其上的Web应用程序不可靠，需要经常重新启动。
因此，IIS6围绕用户的Web应用程序不能运行超过24个连续小时，相应地计划function以及select默认值的前提（非常愤世嫉俗）构build。 工作进程每29小时进行一次回收，进程启动和closures被监视，进程不断地被ping通以确保它正在运行，进程句柄在意外终止时被跟踪和发送信号等。
意识到回收是操作的正常部分，IIS6也确保将这种回收从最终用户中分离出来 – 由于某些内核模式的魔力，最终用户的TCP连接在回收期间永远不会终止。 结合存储会话状态进程外的用户模式应用程序（如ASP.Net会话状态服务），几乎可以保证可靠的正常运行时间，即使Web应用程序在处理完每一个单一事件后崩溃，也不会出现用户可见的数据丢失用户请求。
这与IIS6能做到的一样好 – 由于不可靠的Web应用程序，使其对最终用户看起来可靠，而且不需要任何修复不可靠的Web应用程序。
当然，并不是所有不可靠的应用程序都显得可靠 – 如果是这样的话，那我们就全部失业了！ – 但IIS6肯定会尝试更多的是有弹性的。
在你的情况下，只是弹性对非持久用户状态有副作用，但是可以很容易地调整。
假设您的Web应用程序永远不会有问题，并保持进程内会话状态，您将需要更改这些默认设置：1.closures29小时定期回收2.closures20分钟的空闲超时
这将防止意外的会话状态丢失。
当然，如果您使用的是进程外会话状态的应用程序，则可以将所有内容保留为默认值，并且不会注意到function和可靠性方面的差异。