您好,登錄后才能下訂單哦!
使用 IIS 5.0 時,如果一個運行于低隔離模式或運行于中隔離模式的 Web 網站發生了一次失效,那么重啟網站的唯一方法就是重啟整個 IIS。這樣做會導致 IIS 突然停止服務,所以,在重啟過程中到達的請求都將發生失效。
IIS 6.0 引入了一種革命性的概念,即重疊處理的概念。基于重疊處理的概念,即使一個應用程序池被回收,所有后來到達的請求仍然可以繼續得到服務。IIS 7.0 仍然支持這個概念。
如果某個應用程序池被回收,那么現有的工作進程并沒有馬上退出,而是啟動第二個工作進程,一旦第二個進程啟動成功,Http.sys 隨即將所有的新的請求發送給這個新的工作進程。當現有的工作進程處理完所有請求之后即關閉退出。因為 Http.sys 可以在將到達的請求發送給新的工作進程之前,完成對已到達的請求進行排隊處理的操作,因此,在回收應用程序池的過程中,不會發生丟失頁面請求的現象。
盡管在回收應用程序池的過程中不會發生頁面請求丟失現象,也不會出現頁面請求發生失效的情況,但是對回收過程而言,確實可能存在不良影響,這是因為在回收應用程序池的過程中,所有保存在工作進程中的數據都將丟失。默認情況下,ASP.NET 保存了會話狀態數據和進程內緩存數據(我們稱之為 InProc 數據)。這些數據的有效時間與工作進程的存活時間完全相同,因此在回收應用程序池的過程中,必須重新創建這些數據。所以,必須考慮在進程外保存會話狀態數據。可以在 StateServer、SQLServer,或其他外部會話狀態存儲區中保存會話狀態數據。此外,當啟動一個新的工作進程時,可能會發生加載性能問題。此時,IIS 和 ASP.NET 的各個方面內容都必須加載到工作進程中,因此總的來說加載時間還是比較長的,常常需要耗費幾秒鐘的時間。因此,與應用程序池正常運行情況相比,應用程序池回收之后運行的第一個頁面常常要花費更多時間才能正常運行。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。