公司的一個網站程序長時間運行後，速度變慢，重新啟動網站後速度明顯變快，估計是網站程序占用的內存和CPU資源沒能及時釋放，才需要每隔一段時間重啟網站釋放資源。但手工重啟總不能算解決問題的方法，怎樣才能實現自動管理呢？IIS6.0的應用程序池自動回收功能可以解決這一問題。
應用程序池是將一個或多個應用程序鏈接到一個或多個工作進程集合的配置。因為應用程序池中的應用程序與其他應用程序被工作進程邊界分隔，所以某個應用程序池中的應用程序不會受到其他應用程序池中應用程序所產生的問題的影響。
為Web程序配置應用程序池需要以下步驟：1）創建應用程序池，右鍵單擊“應用程序池”，“新建/應用程序池”，命名為KefuAppPool；2）為Web程序指定應用程序池，在網站虛擬目錄屬性“應用程序設置”裡面的“應用程序池(N)”裡選擇KefuAppPool；3）應用程序池自動回收方式的設置。回收方式有如下幾種：//本文來自www.45it.com
a.根據運行時間
系統默認是1740分鐘,也就是29個小時,這個不是很好控制,建議不用。
b.請求數目
這個要看具體的情況了。如果只有10個請求，可是有5個都在請求那個比較占資源的頁面（可能是統計年度報表之類），這個時候就會出現進程當掉的情況，如果請求有1000個可是一個也沒運行比較占資源的頁面，這個時候進程肯定是很正常的，所以根據請求的數目來決定也不一定符合實際需要。
c.計劃的時間
這個其實很好，不過具體什麼時間回收好呢？通常我們都是設置在凌晨兩三點鐘，這個時候回收是有必要的，不過針對出現隨時可能出現是高內存占用並不是很適用。
d.內存（虛擬內存或已使用的內存）
這個針對出現內存問題引起的進程當掉實在太合適了，不過設置多大的值比較好是一個很重要的問題，值不能太小了，否則如果訪問量都很大超過這個值的時候也會自動回收，這個就很沒必要了。一定要多多觀察進程的實際占用情況再做決定。
下面重點談談對工作進程回收應用程序池的理解。
默認情況下，WWW服務建立“重疊回收”，即繼續運行要終止的工作進程，直到啟動新的工作進程後為止。 在重疊回收方案中，要回收的進程繼續處理請求，同時 WWW 服務創建一個替代工作進程。在停止舊工作進程之前啟動新的工作進程，然後將請求定向到新的進程。此設計可以防止服務中斷，因為舊進程關閉前仍然保持與 HTTP.sys 的通信以處理請求。因為可重疊關閉或啟動的關閉超時值是可以配置的，所以在工作進程仍在處理請求的同時可以終止該進程（如果它在時間限制內沒有處理完請求的話）。
注意：當 WWW 服務回收某個工作進程時，它並不斷開現有的 TCP/IP 連接。HTTP 協議堆棧 (HTTP.sys) 建立並維護 TCP/IP 連接。
IIS中的每個應用程序池由一個“工作進程”進行管理，也就是"W3wp.exe" 進程。如果有多個應用程序池中的程序運行，我們就能看到多個w3wp.exe。這點可以在任務管理器中看到，如下圖所示，任務管理器中有兩個w3wp.exe進程，恰好對應兩個有應用程序在運行的應用程序池。
在命令提示符下運行iisapp -a，可以查看w3wp.exe和哪個應用程序池關聯。1）在任務管理器中增加顯示pid字段；2）在命令提示符下運行iisapp -a。注意，第一次運行，會提示沒有js支持，點擊確定。然後再次運行就可以了。這樣就可以看到pid對應的應用程序池。如上圖左側所示，應用程序池KefuAppPool和PID=3232的w3wp.exe相關聯，應用程序池ReportServer和PID=3572的w3wp.exe相關聯.
下圖顯示了手動執行應用程序池KefuAppPool的回收，在回收前，回收中和回收後應用程序池和工作進程情況。我們注意到：回收過程中增加了一個工作進程（PID=3896），該工作進程（PID=3896）啟動好後，舊的工作進程（PID=5716）才被停止，新工作進程（PID=3896）正式替代舊進程工作，這就很好的防止了應用程序池回收過程中服務被中斷，保證了程序的連續運行。而其他兩個應用程序池對應的工作進程PID都沒用變。該圖很好的展示了應用程序池回收的過程。
IIS應用程序池自動回收機制給我們帶來便利的同時，也會造成潛在的問題。編寫依賴於Global文件中全局事件的函數時我們要特別注意了，尤其是每天定時執行的函數，因為重新啟動IIS應用程序池後，如果沒有用戶訪問網站，則無法激活Application_Start事件，函數也就無法執行了。
