ASP.NET Web Garden模型
Web Garden模型
Web Garden模型可以通過 machine.config 文件中的 <processModel> 部分進行配置。請注意，<processModel> 部分是唯一不能放在應用程序特定的 web.config 文件中的配置部分。這就是說，Web Garden 模式可以應用到計算機中運行的所有應用程序。但通過使用 machine.config 源文件中的 <location> 節點，可以針對各個應用程序調節計算機的設置。
<processModel> 部分有兩個屬性可以影響 Web Garden模型，它們是 Web Garden 和 cpuMask。Web Garden 屬性接受布爾值，表示是否使用了多個輔助進程（一個相關的 CPU 對應一個進程）。默認情況下，該屬性的值為 false。cpuMask 屬性保存一個 DWORD 值，該值的二進制表示為能夠運行 ASP.NET 輔助進程的 CPU 提供了位屏蔽。其默認值為 -1 (0xFFFFFF)，表示可以使用所有可用的 CPU。如果 Web Garden 屬性為 false，則 cpuMask 屬性的內容將被忽略。cpuMask 屬性還為正在運行的 aspnet_wp.exe 的副本數設置了上限。
常言道“閃光的不都是金子”，用在這里很合適。Web Garden 模式使得多個輔助進程可以同時運行。但是，需要注意的是所有進程都會有自己的應用程序狀態、進程內會話狀態、ASP.NET 緩存、靜態數據以及運行應用程序所需的其他內容。啟用 Web Garden 模式之后，ASP.NET ISAPI 將根據 CPU 的數量盡可能多地啟動輔助進程，每個輔助進程都是下一進程的完整克隆（每一進程都與相應的 CPU 密切相關）。為平衡工作負荷，傳入的請求以單循環的方式在運行的進程之間進行劃分。輔助進程就象在單處理器中一樣被回收。請注意，ASP.NET 繼承了操作系統中所有的 CPU 使用限制，并且不包括實現限制的自定義語義。
總之，Web Garden模型并不適用于所有應用程序。應用程序的狀態越多，其的性能損失也越多。工作數據存儲在共享內存的塊中，以便一個進程輸入的變化可以立即被其他進程得知。但是，處理請求時，工作數據被復制到進程的上下文中。因此，各個輔助進程將處理自己的工作數據，而應用程序的狀態越多，性能損失就越大。鑒于此，仔細、明智的應用程序基準測試是絕對必要的。
只有重啟 IIS 后，對配置文件中 <processModel> 部分所做的更改才會生效。在 IIS 6 中，Web Garden 模式的參數保存在 IIS 配置數據庫中，Web Garden 和 cpuMask 屬性被忽略。
HTTP 管道
ASP.NET ISAPI 擴展啟動輔助進程后，它將傳遞部分命令行參數。輔助進程使用這些參數來執行加載 CLR 前需要執行的任務。傳遞的值包括：COM 和 DCOM 安全性所要求的身份驗證等級、可以使用的命名管道的數量和 IIS 進程標識。命名管道的名稱是使用 IIS 進程標識和允許的管道數隨機生成的。輔助進程不接收可用管道的名稱，但可以接收識別管道名稱所需的信息。
COM 和 DCOM 安全性與 Microsoft® .NET Framework 有何關系？實際上，CLR 是作為 COM 對象提供的。更準確地說，CLR 本身不是由 COM 代碼構成的，但是指向 CLR 的接口卻是一個 COM 對象。因此，輔助進程加載 CLR 的方式與加載 COM 對象的方式相同。
當 ASPX 請求遇到 IIS 時，Web 服務器將根據選擇的身份驗證模型（匿名、Windows、Basic 或 Digest）來分配一個令牌。當輔助進程收到要處理的請求時，令牌被傳遞到輔助進程。請求由輔助進程中的線程獲取。該線程從最初獲取傳入請求的 IIS 線程繼承身份令牌。在 aspnet_wp.exe 中，負責處理請求的實際帳戶取決于在特殊的 ASP.NET 應用程序中是如何配置模擬的。如果模擬被禁用（默認設置），則線程將在輔助進程的帳戶下運行。默認情況下，該帳戶在 ASP.NET 進程模型中為 ASPNET，在 IIS 6 進程模型中為 NETWORKSERVICE。這兩個帳戶都是“弱”帳戶，提供的功能比較有限，可以有效抵擋回復性攻擊 (Revert-to-self Attack)。（回復性攻擊是指將模擬的客戶端的安全性令牌回復到父進程令牌。為輔助進程分配弱帳戶可以挫敗此類攻擊。）
高度概括起來，ASP.NET 輔助進程完成的一項主要任務就是將請求交給一系列稱為的 HTTP 管道的托管對象。要激活 HTTP 管道，可以創建一個 HttpRuntime 類的新實例，然后調用其 ProcessRequest 方法。如前所述，ASP.NET 中始終只運行一個輔助進程（除非啟用了 Web Garden模型），該進程在獨立的 AppDomain 中管理所有的 Web 應用程序。每個 AppDomain 都有自己的 HttpRuntime 類實例，即管道中的輸入點。HttpRuntime 對象初始化一系列有助于實現請求的內部對象。Helper 對象包括緩存管理器（Cache 對象）和內部文件系統監視器（用于檢測構成應用程序的源文件的更改）。HttpRuntime 為請求創建上下文，并用與請求相關的 HTTP 信息填充上下文。上下文用 HttpContext 類的實例來表示。
另一個在 HTTP 運行時的設置初期創建的 Helper 對象是文本書寫器，用于包含瀏覽器的響應文本。文本書寫器是 HttpWriter 類的實例，此對象對頁面代碼以編程方式發送的文本進行緩存。HTTP 運行時被初始化后，它將查找實現請求的應用程序對象。應用程序對象是 HttpApplication 類的實例，該類就是 global.asax 文件背后的類。global.asax 在編程時是可選的，但在構建結構時是必需的。因此，如果應用程序中沒有構建類，則必須使用默認對象。ASP.NET 運行時包括幾個中間工廠類，可以用來查找并返回有效的 Handler 對象以處理請求。整個過程中用到的第一個工廠類是 HttpApplicationFactory。它的主要任務是使用 URL 信息來查找 URL 虛擬目錄和匯集的 HttpApplication 對象之間的匹配關系。
應用程序工廠類的行為可以概括為以下幾點：
1. 工廠類維護 HttpApplication 對象池，并使用它們來處理應用程序的請求。池的壽命與應用程序的壽命相同。
2. 應用程序的第一個請求到達時，工廠類提取有關應用程序類型的信息（global.asax 類）、設置用于監視更改的文件、創建應用程序狀態并觸發 Application_OnStart 事件。
3. 工廠類從池中獲取一個 HttpApplication 實例，并將要處理的請求放入實例中。如果沒有可用的對象，則創建一個新的 HttpApplication 對象。要創建 HttpApplication 對象，需要先完成 global.asax 應用程序文件的編譯。
4. HttpApplication 開始處理請求，并且只能在完成這個請求后才能處理新的請求。如果收到來自同一資源的新請求，則由池中的其他對象來處理。
5. 應用程序對象允許所有注冊的 HTTP 模塊對請求進行預處理，并找出最適合處理請求的處理程序類型。這通過查找請求的 URL 的擴展和配置文件中的信息來完成。
HTTP 處理程序是一些實現 IHttpHandler 接口的類。.NET Framework 為常見的資源類型提供了一些預定義的處理程序，包括 ASPX 頁面和 Web 服務。machine.config 文件中的 <httpHandlers> 部分定義了 HttpApplication 對象必須實例化才能處理特定類型資源的請求的類名。如果 Helper 類是一個處理程序工廠，GetHandler 方法將確定要使用的處理程序類型。這時，將從一組類似的對象中獲取適當類型的處理程序，并對其進行配置以處理請求。
【編輯推薦】
