使用 IIS 5.0 時，如果一個運行于低隔離模式或運行于中隔離模式的 Web 網站發生了一次失效，那么重啟網站的唯一方法就是重啟整個 IIS。這樣做會導致 IIS 突然停止服務，所以，在重啟過程中到達的請求都將發生失效。
IIS 6.0 引入了一種革命性的概念，即重疊處理的概念?；谥丿B處理的概念，即使一個應用程序池被回收，所有后來到達的請求仍然可以繼續得到服務。IIS 7.0 仍然支持這個概念。
如果某個應用程序池被回收，那么現有的工作進程并沒有馬上退出，而是啟動第二個工作進程，一旦第二個進程啟動成功，Http.sys 隨即將所有的新的請求發送給這個新的工作進程。當現有的工作進程處理完所有請求之后即關閉退出。因為 Http.sys 可以在將到達的請求發送給新的工作進程之前，完成對已到達的請求進行排隊處理的操作，因此，在回收應用程序池的過程中，不會發生丟失頁面請求的現象。

專注于為中小企業提供成都網站設計、網站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業祿豐免費做網站提供優質的服務。我們立足成都，凝聚了一批互聯網行業人才，有力地推動了成百上千企業的穩健成長，幫助中小企業通過網站建設實現規模擴充和轉變。

    盡管在回收應用程序池的過程中不會發生頁面請求丟失現象，也不會出現頁面請求發生失效的情況，但是對回收過程而言，確實可能存在不良影響，這是因為在回收應用程序池的過程中，所有保存在工作進程中的數據都將丟失。默認情況下，ASP.NET 保存了會話狀態數據和進程內緩存數據（我們稱之為 InProc 數據）。這些數據的有效時間與工作進程的存活時間完全相同，因此在回收應用程序池的過程中，必須重新創建這些數據。所以，必須考慮在進程外保存會話狀態數據?？梢栽?StateServer、SQLServer，或其他外部會話狀態存儲區中保存會話狀態數據。此外，當啟動一個新的工作進程時，可能會發生加載性能問題。此時，IIS 和 ASP.NET 的各個方面內容都必須加載到工作進程中，因此總的來說加載時間還是比較長的，常常需要耗費幾秒鐘的時間。因此，與應用程序池正常運行情況相比，應用程序池回收之后運行的第一個頁面常常要花費更多時間才能正常運行。