作者:斯科特 福賽斯/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，從沒聽說每隔多少小時自動回收，自己給自己還來個最大並發請求數的限制......