前面我們了解了IIS 6.0體系結構的關鍵組件，下面來看看有關應用程序池的一些問題。應用程序池的“屬性”對話框有四頁――回收，性能，運行狀況，標識，如圖六所示。在這些選項頁中，最引人注目的恐怕就是“回收”頁，使用該選項頁可以管理工作進程的回收。在工作進程隔離模式中，IIS可以配置成定期重新啟動應用程序池中的工作進程，從而更好地管理那些有錯誤的工作進程。這確保了池中的應用程序運行正常，并且可以恢復丟失的系統資源。為了回收工作進程，失敗工作進程接收請求的能力將被限制，直到它處理完存儲在請求隊列中的所有剩余請求。為了排出當前請求，可以給予進程配置限制。同一命名空間組的替換工作進程在舊的工作進程停止前啟動，從而防止服務中斷。舊的進程完成其未決的請求，然后正常關閉，或者如果在達到了配置的時間限制、請求數、設置的時間計劃，或當達到指定的內存用量限制后仍沒有關閉，則明確地終止進程。默認情況下，應用程序池每隔1740分鐘（29小時）回收一次。

　　W3SVC根據“運行狀況”頁的選項來判斷應用程序池運行是否正常，包括：每隔指定的時間Ping工作進程，時間按秒計，默認值30秒；啟動時間限制（工作進程必須在指定的時間內開始）；關閉時間限制（工作進程必須在指定的時間內關閉）；是否啟動快速失敗保護（如果在指定的時間段內一定數目的工作進程發生失敗，則禁用應用程序池）。另外，ISAPI應用程序（包括ASP.NET和asp.dll）可以聲明自己不再適合提供服務，要求回收。

　　默認情況下，當IIS 6.0回收一個池時，它會使用一種稱為overlapped recycle的回收技術。在這種回收模式下，失敗的工作進程仍會保持運行狀態，同時創建一個新的工作進程。IIS 6.0把新傳入的請求傳遞給新的工作進程，但不拆除老的工作進程，直至老的工作進程處理完它隊列中的請求，或者遇到超時錯誤。在此期間，TCP/IP連接不會丟失，因為有http.sys保持著連接的有效性。當失敗的工作進程超時出錯時，下一個請求傳遞給工作進程的請求是新的請求，因此原來保存在進程中的會話信息就會丟失。所有這類回收操作都自動進行，無需管理員干預，而且在大多數情況下，不會造成明顯的服務中斷現象。如有必要，可以將配置數據屬性LogEventOnRecycle的值設置為1，指示W3SVC執行回收操作時生成一條事件日志記錄。

　　對于那些不能以多個實例運行的應用程序，overlapped recycle回收技術可能引起問題。如果遇到這類問題，可以將配置數據屬性DissallowOverlappingRotation的值設置成True（1），關閉某個應用程序池回收操作時的進程“重疊”現象。另外，對于失敗的工作進程，有時我們可能不想將它拆除，仍舊保留該進程，以便檢測和尋找發生問題的根源，這時可以將配置數據屬性OrphanActionExe設置成執行文件的名字，使得工作進程成為“孤兒”時執行文件仍保持運行狀態。

　　另一個與應用程序池有關的特性是，IIS 6.0允許將應用程序池配置成一個Web園（Web Garden）。要理解Web園的概念，可以設想這樣一種情形：假設有一個IIS 5.0服務器和三個Web網站，每一個Web網站運行著相同的應用程序，如果IIS 5.0能夠自動按照圓形循環的模式將請求依次發送給這些功能上等價、實際上分離的Web網站，將負載分離到三個不同的進程，就可以構成一個小型的Web農場（Web Farm）――這就是Web園。

　　在IIS 6.0的Web園中，我們不必創建額外的Web網站，只要指定用于某個應用程序池的工作進程的數量就可以了。具體的配置步驟是：打開應用程序池的“屬性”對話框，轉到“性能”頁，在“Web園”下面的“最大工作進程數”輸入框中輸入進程數量，如圖八。當服務器的負載較小，不需要額外的工作進程時，IIS 6.0在一定的時間后（默認20分鐘，可配置）自動縮減實際的工作進程數量；如果負載變大，需要額外的工作進程，IIS 6.0再次增加工作進程數量。這一切操作都自動進行，不需要管理員干預。

　　兩個新的配置數據屬性――SMPAffinitze和SMPAffinitzeCPUMask――允許配置為工作進程指派的特定處理器：將SMPAffinitized屬性設置成true表示應該把分配給應用程序池的特定工作進程指派給特定的CPU，SMPProcessorAffinityMask屬性用來配置十六進制的處理器掩碼，該十六進制處理器掩碼指出應用程序池中的工作進程應該綁定到哪個CPU。

　　寫到這里，文章的篇幅似乎已經太長了。本文主要從體系結構的角度介紹IIS 6.0的新特性，并且盡力做到全面，至少要比通常見到的介紹更完善一些。文章的第二部分將涵蓋更多的IIS 6.0新特性，你會發現許多新特性正是自己長久以來盼望的。