如果Web服務器操作系統是Windows server 2003,則IIS 6.0進程模型是asp.net的默認選擇。其名稱明確之處,該模型需要IIS 6.0、然后,在windows 2003 的服務器上,仍然可以讓asp.net遵守IIS 5.0進程模型的規則。可以通過修改machine.config文件中的<processModel>節,顯示的啟用該模型。
<processModel enable="true">
當然,我并不建議且滑倒IIS 5.0進程模型,雖然這樣做是合法的。主要原因在于:IIS 6.0利用不同的內部模塊的管道來處理一個入站請求,并且只有在仿真模式下運行時才能模仿IIS 5.0的行為。IIS 6.0管道以一個名為 完wp.exe的工作進程為中心。所有被分配給同一個應用程序池的Web應用程序共享該可執行進程的一個副本。用IIS 6.0的行話來說,一個應用程序池是一組共享相同的工作進程的副本的Web用用程序。IIS 6.0使我們能夠指定應用程序池,以實現Web服務器上托管的各應用程序所需的隔離程度。
w3wp.exe worker進程加載aspn_isapi.dll;該ISAPI擴展又加載通用語言運行庫(CLR),并啟動ASP.NET運行庫管道來處理該請求。當IIS 6.0進程模型正在使用時,內置的ASP.NET工作進程會被禁用。
注意:只有asp.net1.1完全利用IIS 6.0進程模型。如果把asp.net1.0安裝到一臺windows 2003 機器上,則默認的進程模型是IIS 5.0進程模型。之所以會這樣,是因為asp.net1.1所帶的aspnet_isapi.dll能夠識別它的宿主,并根據需要加載CLR。asp.net1.0所帶的aspnet_isapi.dll只能把請求轉發給asp.net工作進程,絕對不會加載CLR。
下圖為IIS 6.0進程模型
IIS 6.0作為內核級模塊實現其HTTP監聽程序。因此,所有的輸入請求首先由http.sys驅動程序以內核模式進行管理。沒有任何的第三方代碼會與該監聽程序交互,并且沒有任何的用戶模式沖突會影響IIS的穩定性。http.sys驅動程序監聽請求,并把他們投遞到合適的應用程序池的請求隊列。一個稱為餓哦Web管理服務的模塊讀取IIS 冤苦,并指示http.sys驅動程序創建與元庫中所注冊應用程序池一樣多的請求隊列。
總之,在IIS 6.0進程模型下,asp.net運行的更快,因為在inetinfo.exe可執行進程和工作進程之間,不需要任何進程間的通信。http請求直接在托管CLR的工作進程中被交付。此外,asp.net工作進程不是一個特俗進程,它只是IIS工作進程的一個副本。這一事實將進程回收、頁面輸入緩存和運行狀況檢查的負擔(轉交給IIS)
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
