[翻译]为何IIS应用程序池回收时间默认被设置为1740分钟?

做者:斯科特 福赛斯/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，从没据说每隔多少小时自动回收，本身给本身还来个最大并发请求数的限制......