作者:斯科特 福赛斯/Scott Forsyth
日期:2013/04/06
地址:http://weblogs.asp.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes
微软IIS服务器在应用程序池回收时间上有一个看上去有点古怪的默认设置。它默认为1740分钟，也就是整整29小时。对于这个"默认"到底是从哪儿来的，我已经好奇很久了。如果你跟我一样，那你一定也想知道答案很久了。[译注:这其实就是我当初搜索并简单翻译这篇文章的原因]
答案马上揭晓!今年在Bellevue WA举办的MVP峰会上，我又获得了跟IIS团队沟通的机会。韦德 赫尔墨[译注:关于韦德 赫尔墨的链接]也在场。谈话中话题逐渐就转到IIS默认设置是怎么来的上面了，自然包括那个奇怪的针对应用程序池回收时间的1740分钟。韦德告诉了我它的由来并且"批准"我与大家分享。
你可以想象，微软研发的大量产品，围绕着它们所作出的设计决策必然是经过了长时间的深思熟虑和研究，难道不是吗?但确实有一部分决策，它们的来源有点任性和有趣，咱们谈论的这个就属于后者。
1740的故事
让时光倒转回IIS 6正在被研发的时候吧，这个版本也是引入"应用程序池"概念的版本。由于应用程序池默认被设置为自动回收，自然就需要一个默认的自动回收时间间隔。
韦德提议选择29小时作为默认时间间隔，理由很简单：它是大于24的最小素数。他想要一个频度比一天一次大，交错分开而且不重复的模式。用他的话说"你不会想要一个周期性的模式"。从此默认设置就是1740分钟(29小时)了!
这就是关于1740由来的小故事。然而在你面对具体环境时又该如何呢?怎样的默认设置才算是合适的?
实践指导
首先，我觉得29小时是个不错的选择。对于一个你不了解具体情况的环境，它是适用的，选择一个非周期重复的模式而不是一天一次是个好主意。
然而，如果你比较了解你的环境的话，最好改变默认设置。我建议设置成在固定时间回收，比如你在美国东海岸那就4点，西海岸呢那就1点，反正就是挑网站用户少、网站流量低的时候。在每天流量低的固定时间做回收能把回收的影响降到最低而且可以当你遇到问题时使调试和跟踪工作更轻松。如果你有多个应用程序池错开它们的回收时间点会是很明智的，这样就不会因为大量并发回收使得服务器过载了。
注意，IIS会在回收时"重叠"应用程序池[译注:所谓"重叠"应用程序池，翻译的有点硬，原文是"Note that IIS overlaps the app pool when recycling"，我猜测就是干掉老池前先启动一个新池，等新池把工作都接手后再干掉老池，Nginx平滑升级就是类似这样的，先启动一个新 Worker，等新Worker把工作都接手后再干掉老Worker，个人猜测。]，所以一般来说在回收时不会停止提供服务。然而，内存中信息(比如Session)会丢失。如果你对IIS在回收时"重叠"应用程序池这个主题感兴趣，请看这个视频。
你也许会问一个固定时间的回收机制是否是必需的。一个每日定时回收的机制就像是在发生轻微内存泄露或者其它拖累Worker进程的因素的情况下，刷新IIS的创可贴[译注:关于创可贴(band-aid or let's say "邦迪")，我理解他意思是指不能从根儿上使问题不再复现但是使问题能得到控制的解决方案，个人猜测。]。理论上不需要它，除非你真的碰到了这样的问题。我曾经建议如果不需要就干脆完全关闭这个机制。然而，现在我已经认识到，设置应用程序池在每天的非高峰时段进行回收是很积极的举措。
我的理由如下，首先，你的网站应当能够避免受到"回收"造成的影响，"每日定时回收"值得考虑。其次，我发现即便你"体贴"的对待应用程序池，随着时间的流逝，最终还是会出现影响应用程序池的问题。从导致应用程序过度缓存或其它奇怪事情的流量模式中，我已经发现了问题，除此之外，我还发现了非常罕见的IIS bug(是的，很罕见)，而如果你做每日定时回收那么这个bug就不再是问题了。它到底是不是个创可贴呢?可能吧，但如果每日定时回收能够避免很多非严重性的问题那么我觉得这是个能省去大量跟踪调试工作(跟踪调试的问题本身可能还不是那么值得花时间去处理)的积极举措。然后，如果你真的有一个因为回收机制而受到影响的问题[译注:我曾经碰到过这样的问题，当时经手一个Web项目，需求方需要一个计时机制，7*24，项目中也实现了一个计时器，但因为应用程序池回收机制的存在，当然也包括那个闲置时间的设置，总是出问题，后来提议"计时逻辑"实现到一个Windows service中去了。],在试过其它手段之后，那么就关掉这个自动回收机制吧，然后跟踪和尝试解决你的问题。在这点上，没有非黑即白的明确答案。只有你才能针对你面对的具体环境做出合理的决策。
"闲置时间"(Idle Time-out)
在应用程序池默认设置上，还有一个设置，你每次做服务器部署时都应当改变。这个就是"闲置时间"，应当被设置为0除非你在服务器上部署大量网站并且希望使平均每个网站的内存消耗降到最低。
如果在你的服务器上有一个或少量的网站并且你希望它们可以迅速的加载，那么设置这个值为0。否则，一旦无人访问网站的时间超过20分钟，应用程序池就会中止直到下次访问到来再进行重启。问题在于首次对应用程序池的访问将创建新的w3wp.exe工作进程，这个过程比较耗费资源，具体说，应用程序池需要创建、ASP.NET或其它框架需要加载，然后你的应用程序本身也要加载。这个过程可以耗费达几秒的时间。所以我每次都把这个值设置为0，除非在你的服务器上寄宿着很多不需要总是保持运行状态的网站。
针对具体环境，当然还有其它需要留意的设置，但上述两个几乎是每次都应更改的设置。
希望你喜欢这篇讲述“29小时默认设置”由来的文章，哪怕仅仅是觉得有趣。快乐的继续使用“IIS”吧。
译者关于IIS默认设置的吐槽
默认每隔29小时自动回收、默认超过20分钟无人访问也回收还有默认最大并发请求数5000(<applicationPool maxConcurrentRequestsPerCPU="12" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>)，尤其最后一个，当初吓了我一跳，还以为这么快系统就挂了呢......IIS打个比喻就像是个富二代，外表精致、优雅，但这几个默认设置怎么显得那么有弱不禁风的嫌疑呢?那些野孩子比如Nginx,Lighttpd，从没听说每隔多少小时自动回收，自己给自己还来个最大并发请求数的限制......