[翻譯]爲何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，從沒據說每隔多少小時自動回收，本身給本身還來個最大併發請求數的限制......