重疊處理

使用 IIS 5.0 時，若是一個運行於低隔離模式或運行於中隔離模式的 Web 網站發生了一次失效，那麼重啓網站的惟一方法就是重啓整個 IIS。這樣作會致使 IIS 忽然中止服務，因此，在重啓過程當中到達的請求都將發生失效。
IIS 6.0 引入了一種革命性的概念，即重疊處理的概念。基於重疊處理的概念，即便一個應用程序池被回收，全部後來到達的請求仍然能夠繼續獲得服務。IIS 7.0 仍然支持這個概念。
若是某個應用程序池被回收，那麼現有的工做進程並無立刻退出，而是啓動第二個工做進程，一旦第二個進程啓動成功，Http.sys 隨即將全部的新的請求發送給這個新的工做進程。當現有的工做進程處理完全部請求以後即關閉退出。由於 Http.sys 能夠在將到達的請求發送給新的工做進程以前，完成對已到達的請求進行排隊處理的操做，所以，在回收應用程序池的過程當中，不會發生丟失頁面請求的現象。

儘管在回收應用程序池的過程當中不會發生頁面請求丟失現象，也不會出現頁面請求發生失效的狀況，可是對回收過程而言，確實可能存在不良影響，這是由於在回收應用程序池的過程當中，全部保存在工做進程中的數據都將丟失。默認狀況下，ASP.NET 保存了會話狀態數據和進程內緩存數據（咱們稱之爲 InProc 數據）。這些數據的有效時間與工做進程的存活時間徹底相同，所以在回收應用程序池的過程當中，必須從新建立這些數據。因此，必須考慮在進程外保存會話狀態數據。能夠在 StateServer、SQLServer，或其餘外部會話狀態存儲區中保存會話狀態數據。此外，當啓動一個新的工做進程時，可能會發生加載性能問題。此時，IIS 和 ASP.NET 的各個方面內容都必須加載到工做進程中，所以總的來講加載時間仍是比較長的，經常須要耗費幾秒鐘的時間。所以，與應用程序池正常運行狀況相比，應用程序池回收以後運行的第一個頁面經常要花費更多時間才能正常運行。