为什么IIS工作进程每29小时而不是每24小时回收一次？

当您在IIS上设置站点时，默认情况下工作进程每隔1740分钟（29小时）进行回收。为什么要选择29小时而不是24小时或48小时这样的奇数？

在Tech Ed 2003上，演示者被问到这个问题，答案是他们希望有一个不规则的循环来防止它在日常边界上发生（例如，与服务器/域上计划的其他日常任务区分开）。

这里的网站（链接无效）推测：

...（29是）24之后的第一个素数，使它在任何其他服务器进程中以规则模式发生的可能性最小；简化对问题的调查

另一个站点似乎确认了这一点：

（Wade Hilmo）建议使用29小时，原因很简单，因为它是24时最小的素数。他希望采用一种交错且非重复的模式，该模式不会每天发生一次以上

好的，这困扰着我，所以我仔细研究了一下，终于找到了一个显然是IIS团队成员的帖子：

IIS6默认每29小时回收一次的原因（我们有一个理由

IIS6默认情况下每29小时回收一次（我们有选择29小时作为默认值的原因）的原因是，很有可能，运行在它上面的Web应用程序不可靠，并且实际上需要经常重新启动。

因此，IIS6的构建是基于这样一个前提（公认地愤世嫉俗的）：用户的Web应用程序将不会运行超过24个连续小时，相应地计划功能，并选择默认值。辅助进程每29小时循环一次，监视进程的启动和关闭，对进程进行持续ping操作以确保其正在运行，对进程句柄进行跟踪并在其意外终止时发出信号，等等。

意识到回收是操作的正常部分，IIS6还确保将这种回收与最终用户隔离开来-由于某些内核模式魔术，最终用户的TCP连接在回收期间永远不会终止。结合存储进程外进程状态的用户模式应用程序（如ASP.Net会话状态服务），即使Web应用程序在处理每一个单独的应用程序后崩溃，它实际上也可以保证可靠的正常运行时间，而不会造成用户可见的数据丢失用户要求。

这与IIS6所能达到的效果差不多-给定不可靠的Web应用程序，使其对最终用户看起来可靠，并且不需要对不可靠的Web应用程序进行任何修复就可以做到这一点。

当然，并非所有不可靠的应用程序都可以看起来可靠-如果是这样，那么我们都失业了！-但IIS6肯定会尝试更多以提高弹性。

在您的情况下，弹性只会对非持久性用户状态产生副作用，但可以轻松进行调整。

假设您的Web应用程序永远不会出现问题，并且处于进程内会话状态，那么您将需要更改以下默认值：1.关闭29小时的定期回收2.关闭20分钟的空闲超时

这将防止会话状态意外丢失。

当然，如果您曾经使用进程外会话状态的应用程序，则可以将所有内容保留为默认值，而永远不会注意到功能或可靠性上的差异。