IIS为什么默认为每1740分钟回收一次应用程序池？

为什么IIS在给定时间后默认默认回收应用程序池？除了大多数Web应用程序可能不谨慎管理内存外，还有其他特定原因吗？鉴于您正在正确管理应用程序的内存，可以安全地将其关闭吗？关闭回收或继续回收有哪些潜在的不利方面和向上的好处？

是的，它默认为每天一次的原因是出于担心Web应用程序可能发生内存泄漏的担心。频繁回收IIS应用程序池的最大弊端是，它将导致web.config读取，程序集加载和asp.net页面的重新编译，以及（如果您不相信它们的预编译）代码的背后。这是一个相当繁重的过程，直到应用程序池回收后下一个页面请求才发生，这大大降低了该特定请求的速度。IIS7现在有一个模块，您可以下载名为Application Warm Up的模块来帮助解决此问题。

我个人更喜欢将基于内存的最大值与登录应用程序启动结合使用，而不是安排回收。这使我可以假定我的应用程序没有内存泄漏，并且在应用程序池回收时被证明是错误的。

1740分钟是29小时：

回到IIS 6开发时（引入应用程序池的版本），当应用程序池被自动回收时，需要为“常规时间间隔”设置默认值。

韦德建议使用29小时，原因很简单，因为这是24小时内最小的素数。他想要一种不重复的，不重复的模式，这种模式每天不会发生得最多。用韦德的话说：“你不会产生共鸣”。从那时起，默认设置为1740分钟（29小时）！

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

功能是经典ASP时代的遗留物，当时一切都泄漏了内存，您必须这样做。大多数人都计划在一夜之间在Web服务器上重新启动。IIS6通过每隔1740分钟（或如果应用程序空闲20分钟）关闭应用程序池来自动执行此操作。IIS7延续了这一传统。

那时我从微软那里得到的建议是，除非您有一个已知内存泄漏的旧版应用程序，否则这是没有必要的。因此，如果您运行的是纯托管代码，则可以。

关闭它并监视应用程序池。大多数复杂的企业应用程序都使用大量的旧代码，并且其中许多代码都是泄漏的。因此，对于大多数安装，偶尔重新启动应用程序池并不是一个坏主意。

还有其他选项，例如监视不活动时间，这可能是针对您情况的更好解决方案。

加速应用程序池可能会花费一些时间，并使应用程序的响应速度降低，因此，保持它们正常运行可以帮助提高性能。

实际上，这纯粹是为了清理（可能）存在的泄漏资源。1740分钟也不是唯一触发事件。在特定的最大请求数之后或超过特定数量的工作进程内存之后，也会发生这种情况。它在MSDN库中有很好的记录。不幸的是，此策略破坏了会话状态和静态状态（例如单例）。您的应用程序将需要足够强大，以便根据需要重新验证用户和/或重新初始化单例，以免打扰用户的体验。它迫使我们在数据库而不是ASP.NET会话中管理经过身份验证的会话。否则，由于这些触发器之一，每当服务器回收时，我们的用户就会被引导回到我们的登录页面。