IIS 7.0 中的 10 大性能改進

IIS 7.0 中的 10 大性能改進

Mike Volodarsky

 

概覽：

• 最小化應用程序佔用空間
• 降低帶寬成本
• 使用增強的緩存功能

 目錄

進一步瘦化 Web 服務器
構建在瘦操作系統上
專用的應用程序拓撲
改進的應用程序支持
增加應用程序密度
通過壓縮來降低帶寬
媒體比特率限制
輸出緩存
將 ISAPI 代碼轉換成 IIS 7.0 模塊
服務器可擴展性
結束語

當我與計劃採用 IIS 7.0 的公司會面交談時，每次都要提到的一個問題就是遷移到 IIS 7.0 是否會改善服務器或應用程序的性能。答案

通常是肯定的，但如果在將應用程序剛剛遷移到 IIS 7.0 時並沒有看到任何性能改善，也請不要感到驚訝。

要理解這一點，您需要了解最新版本自身的一些特點。IIS 6.0 是工程版本，旨在實現以下三個目標：更強的安全性、更高的可靠性以及改進的性能。相比之下，IIS 7.0 是一個平臺版本。它的目的是將其前身所擁有的高質量基本 Web 服務器核心轉換成支持重要最新部署和管理方案的模塊化和可擴展平臺。

體系結構的許多變更和新增功能實際上可能會對 Web 服務器的性能產生負面影響 — 例如，假定有一個關鍵變更，它將經過嚴格優化的 Web 服務器代碼路徑拆分成了多個獨立模塊，這會導致這些模塊將不再受到 Web 服務器的特殊對待。但是 IIS 7.0 則不然，它不但保留了其前身的出色性能，在某些領域甚至有所突破，這一切都應歸因於 IIS 團隊在性能方面所做的大量卓有成效的工作。根據我在 Web 服務器核心和集成管道方面的工作經驗，我可以負責任地說，要實現這一目標需要大量的獨創性設計，還需要在實現產品時付出艱辛的勞動。

儘管如此，與之前的其他 IIS 版本相比，IIS 7.0 還是極有可能會提供顯著的性能改進並減少服務器場的性能相關成本。

您大可不必只爲了解這些優點而遷移到 IIS 7.0，您可以通過某些環境進行了解。例如，Microsoft.com 的 CPU 效率出現了 10% 的改進（可在 Microsoft.com 團隊博客上找到完整的分析，網址爲 go.microsoft.com/fwlink/?LinkId=122497）。您可能還會發現在某些特定領域也有顯著的改進，例如安全套接字層 (SSL) 和 Windows® 身份驗證（現在二者均在內核中執行），此外在多核和多處理器計算機中它也可以提供更出色的垂直可伸縮性。

但是，真正的 IIS 7.0 動力並不是來自於對現有功能的增量性能改進。相反，應該說這些改進源自於您會主動使用的新增功能。這些功能通常來源於平臺的靈活性和可擴展特性以及一些新的性能特性。在本文中，我將向您展示通過遷移到 IIS 7.0 可以實現的 10 個最重要的性能改進。

進一步瘦化 Web 服務器

部署瘦 IIS 7.0 服務器的能力借用的是服務器的模塊化體系結構。實際上，所有 Web 服務器功能都是以模塊化組件的形式實現的，可以單獨進行添加或刪除。這樣一來，您可以將那些對於應用程序的操作而言並非必需的所有服務器功能刪除，這可以帶來一些明顯的益處，包括極大地減少受攻擊的機會、減少操作內存佔用量以及改善性能。

完整的 IIS 7.0 Web 服務器功能集由 44 個模塊組成，包括爲集成管道提供服務的本機 IIS 模塊和 ASP.NET 模塊。這些模塊可以提供多種服務，如身份驗證（Windows 身份驗證和摘要身份驗證模塊）、應用程序框架支持（FastCGI 模塊）、應用程序服務（會話狀態模塊）、安全性（請求過濾模塊）和性能（輸出緩存模塊）。對於僅提供靜態內容的最小 Web 服務器，它只需要 2 個模塊就可以正常運行！

對於那些不必要的模塊，其開銷可能會相當顯著 — 例如請求記錄和失敗請求跟蹤模塊。將此類模塊從不需要它們的環境中移除可得到更高的總吞吐量和更快的響應，因爲這可以減少服務器工作負載收到第一個字節的時間 (TTFB) 和收到最後一個字節的時間 (TTLB) 度量。

圖 1 顯示了在使用完整功能集時、使用工作負載的默認功能集時以及使用工作負載必需的最小功能集時，針對 HTML 文件（靜態工作負載）和 hello world ASP.NET 頁面（ASP.NET 工作負載）進行簡單吞吐量測試所得到的結果。儘管大部分不必要的功能在“完整”配置中已被禁用，但在“最小”配置中完全移除它們仍可使靜態工作負載和 ASP.NET 工作負載的吞吐量都得到大幅提升。

圖 1 在具有 100 個併發客戶端的三種不同配置情況下，靜態工作負載和 ASP.NET 工作負載的吞吐率（單擊圖像可查看大圖）

此外，您可能還會發現在內存佔用量方面的改進和更高的站點密度，尤其是在共享託管環境或使用大量工作進程的情況下。這通常是由於向每個進程加載的 DLL 變少，同時還消除了在模塊初始化和請求處理過程中所需的內存分配工作。圖 2 顯示了在相同的吞吐量測試中內存的使用量（IIS 工作進程專用字節）。儘管在此示例中改進並不明顯，但增長是符合預期的，因爲 ASP.NET appdomain 的開銷相對要高於移除模塊所帶來的基線節約開銷。

圖 2 在具有 100 個併發客戶端的三種不同配置情況下，靜態工作負載和 ASP.NET 工作負載的內存使用量（專用字節）（單擊圖像可查看大圖）

IIS 7.0 可以對在應用程序級別啓用哪些模塊提供額外的控制，還可以通過模塊預處理來根據工作負載控制模塊使用量。儘管這需要高級的配置，但在多站點環境中或對於支持多個不同工作負載的應用程序，它可以提供更多的益處。

需要注意的一點是：確定所需功能時可能會比較棘手。您不但必須要考慮支持應用程序框架所需的最少功能，還必須考慮應用程序可能間接依賴的其他功能。例如，您的應用程序可能取決於特定的身份驗證方法或依賴於各種 IIS 功能所提供的授權語義，這時如果移除它們可能會對應用程序的安全性產生負面影響。同樣，您的應用程序可能依賴於某些模塊來實現功能或性能效果，在這種情況下移除它們可能會導致錯誤的行爲或性能損失。

構建在瘦操作系統上

Windows Server® 2008 還提供了操作系統級別的組件化功能，可用於進一步減少 Web 服務器的外圍應用。Server Core 是 Windows Server 2008 操作系統的最小安裝選項，其中包含最小的核心操作系統子系統集。Server Core 是用於瘦 IIS 7.0 Web 服務器的理想環境。

但是，在評估 Server Core 時，要知道某些限制可能影響您的應用程序。Server Core 不提供對 Microsoft® .NET Framework 的支持，這也意味着它不支持 ASP.NET、IIS 的 .NET 可擴展性以及 IIS 管理器。此外，由於沒有 Microsoft 管理控制檯 (MMC) 可供使用，因此本地管理任務需要使用命令行工具。從性能角度來看，如果您已正確利用 IIS 組件化，則在運行 Server Core 和完整的 Windows Server 實現時，您可能不會覺察到應用程序工作負載的內存佔用量或吞吐量的差異。這是因爲 IIS 和您的應用程序所執行的工作在兩個平臺上都是相同的。但是有一個地方可以看到差異：服務器的總佔用量（包括磁盤空間和內存使用量）。

例如，圖 3 顯示了針對完整的 Windows Server 2008 配置和 Server Core 執行靜態工作負載測試後，內存佔用量的差異。儘管在這兩種情況下 IIS 的內存佔用量實際完全相同，但 Server Core 的總操作系統內存佔用量更低，因此相比而言只需更少的內存即可支持此工作負載。在實際當中，更低的內存佔用量可允許在性能較差的硬件中部署應用程序工作負載，因爲它關注的是應用程序的處理需求而非操作環境。當然，這也使得 Server Core 成爲用於虛擬環境的首選。

圖 3 執行靜態工作負載測試後，完整的 Windows Server 2008 與 Server Core 的內存佔用量（單擊圖像可查看大圖）

專用的應用程序拓撲

優化應用程序工作負載時，可將工作負載分成多個不同的部分。例如，您可以在具有 10 個 Web 服務器、5 個應用程序服務器和 3 個代理服務器（用來執行緩存和壓縮操作）的場中運行應用程序，而不是在具有 30 個相同 Web 服務器的場中運行它。

採納特殊處理的原因有多種。首先，許多應用程序工作負載的性能在很大程度上都取決於應用程序的多個部分之間可以競爭得到的各種共享資源（如內存）。此類資源競爭可能產生瓶頸問題，導致各種資源無法充分利用每臺服務器。通過分離應用程序的各個部分，可使其能夠隨時訪問被競爭資源，從而使同樣的硬件資源組發揮更高的效率。

其次，特殊處理可使應用程序獲得更合適的緩存區域，從而改善其性能。這包括低級緩存（如虛擬內存轉換旁路緩衝器 (TLB)）、文件系統緩存以及其他操作系統和應用程序緩存。另一種區域資源來自 CPU。通過僅關注應用程序的特定部分來減少所發生的並行活動數後，應用程序可減少上下文切換次數並將 CPU 的工作效率提高到最大。

第三，特殊處理可實現特定於工作負載的優化，從而使應用程序各個部分的工作效率更高。當在同一個服務器上支持整個應用程序時，由於應用程序的不同部分存在需求衝突，因此許多此類優化都無法實現。

一個經常發生此類情況的位置是 IIS 和 ASP.NET 線程配置，它會對併發性產生直接的影響，並會間接影響許多應用程序的內存使用量、延遲時間和吞吐量。IIS 靜態文件工作負載嚴重不同步，需要施加高併發請求限制，但它只需極少量的可用線程即可正常工作。另一方面，許多 ASP.NET 功能是同步的，但長時間處於阻塞狀態，因此需要較高的線程數，而同時仍有其他一些功能需要較低的併發限制以降低對內存的影響。通過分離靜態工作負載，將部分請求處理管道劃分到不同的進程或服務器，可優化每個單獨工作負載的併發性。

最後，通過允許應用程序分別獨立擴展離散的工作負載或應用程序部件，特殊處理可以實現更出色的總體可擴展性。這可以使應用程序拓撲在最需要的位置提供更高的容量和冗餘性，而不是要求您將相同的模板應用到整個應用程序。在這一模型中，專用資源可能是物理服務器、虛擬服務器甚至是同一臺計算機中的應用程序池。

要評估在應用程序拓撲中特殊化可能帶來的好處，首先應找出應用程序中佔用大量進程或資源的瓶頸。這些方面應作爲特殊化的首要候選對象，因爲在隔離後它們可能具有顯著的優化潛力，並且它們將會需要最高級別的橫向擴展。接下來評估在隔離它們之後，應用程序的剩餘部分是否能更有效地利用資源。最後，還需要評估將隔離的應用程序組件組合在一起所需的連接機制的開銷。

改進的應用程序支持

IIS 7.0 可以通過 FastCGI 實現對應用程序框架的擴展支持，FastCGI 是一種受到許多開源應用程序框架支持的開放式協議，如果不使用 FastCGI，這些應用程序框架可能不支持與 IIS 穩定的、高性能的原生集成。與 IIS 長期以來一直支持的 CGI（通用網關接口）協議不同的是，FastCGI 可以在 Windows 平臺上提供明顯改善的性能。這主要得益於 FastCGI 可重用的進程體系結構，它免去了針對每個請求創建進程的繁重開銷，使客戶端可以利用永久保持活動狀態的連接。

如果您現在是使用 CGI 或其他機制來使 IIS 支持應用程序框架，則遷移到 FastCGI 協議可能會得到更好的性能（有時還可以得到更好的穩定性）。

利用此支持的第一個應用程序框架是 PHP。實際上，IIS 團隊一直在與 Zend Technologies 進行直接的合作以確保 IIS Fast­CGI 實現能與 PHP 良好配合，並能夠給 Windows 中的 PHP 框架帶來性能的改進。（有關此項目的詳細信息，請參閱我博客上的帖子，網址爲 go.microsoft.com/fwlink/?LinkId=122509。）如果您使用的是混合 Web 服務器技術（例如運行在 IIS 上的 ASP 或 ASP.NET 應用程序，以及使用其他技術的 PHP 或與 FastCGI 兼容的其他應用程序框架），則可以在 IIS 7.0 平臺上進一步鞏固這些應用程序。

通過將 PHP 和其他應用程序框架遷移到 IIS 7.0 和 FastCGI，您可以充分利用 IIS 7.0 的各種功能，包括 ASP.NET 集成管道。利用它可以通過 ASP.NET 服務非常方便地增強應用程序框架，而不必再將其轉換到 ASP.NET。並且它還可以使那些使用不同框架的應用程序協同工作。有關如何使用它在不改動任何代碼的情況下來增強現有應用程序並改善應用程序性能的示例，請參閱我撰寫的《MSDN® 雜誌》文章“使用集成的 ASP.NET 管道增強應用程序”（網址爲 msdn.microsoft.com/magazine/cc135973.aspx）。

增加應用程序密度

IIS 7.0 包括許多旨在增加可在單臺服務器上託管的應用程序密度的增強功能。這些增強功能是 IIS 7.0 引入的用來改進共享託管質量的衆多功能中的一部分，其中包括改進的站點置備和更好的應用程序隔離。

從性能角度看，這些改進主要關注在兩個方面增加應用程序密度 — 增加可在單臺 IIS 7.0 服務器上置備的應用程序數量，以及增加可在給定時間內處於活動狀態的應用程序數量。

請注意，IIS 7.0 能夠在每臺服務器上置備的應用程序數量要大幅超出以前，在某些內部測試中，單臺服務器上最多可置備 100,000 個站點。這就爲其賦予了創建和配置大量站點和應用程序的能力。

需要注意的一點是：要實現高速置備，需要遷移到新的配置 API，因爲較老的配置 API 無法實現這一點。此外，並非所有 IIS 配置 API 都提供相同的性能特性，因此必須仔細選擇以確保實現高性能。如果有疑問，可使用直接利用最新 IIS 配置對象的配置選項，其中包括 Microsoft.Web.Administration 命名空間、AppCmd.exe 命令行工具以及 IIS COM 配置對象（可通過腳本、.NET 或 C++ 代碼進行訪問）。

在使用持久應用程序和工作進程來執行請求處理的 IIS 體系結構中，可置備的站點數和可處於活動狀態的站點數之間的差別是一個非常重要的區別。在此模型中，活動的應用程序會消耗服務器上更多的資源，但同時它也會由於緩存和免去初始化成本等原因而提供更好的持續性能。

由於每個活動的應用程序都需要特定數量的內存和單獨的工作進程（如果使用的是建議的應用程序隔離模型），所以活動應用程序的數量在很大程度上取決於應用程序的內存佔用量。因此，對於僅提供靜態內容的單個應用程序，其工作進程可能只需要 3MB 的內存（甚至還可以與其他靜態內容應用程序共享同一個工作進程），但某些動態應用程序即使在低使用率情況下也可能需要 100MB 甚至更多的內存。這樣一來，在定義最大的可能密度時，與應用程序的內存使用量相比，IIS 工作進程本身的內存開銷就顯得無關緊要了。

在典型的共享託管情形中，經常可以看到被稱爲 80/20 分佈的現象，即 80% 的請求被轉到 20% 的站點。這會導致少量站點始終處於活動狀態。爲允許更大數量的活動站點，IIS 7.0 提供了活動的生命週期管理。這可以幫助您從非活動應用程序回收內存以允許託管更多的活動應用程序。

IIS 7.0 引入了一種稱爲動態空閒的新算法，它可以根據服務器的可用內存主動調整工作進程的空閒超時時間。隨着內存逐漸減少，刪除空閒應用程序的速度會加快，因此允許託管更多的活動應用程序。但是，在有內存可用的情況下，此超時時間可維持一個比較大的數值，以提供更好的性能並維護應用程序狀態。除了允許更多的應用程序處於活動狀態外，動態空閒還有助於避免低內存狀況出現，這種狀況會由於超負荷而導致嚴重的性能降級。

要實現大量活動應用程序的託管，還應採用 64 位操作系統，因爲它允許操作系統處理超過 4GB 的內存。此外，您還可以將 IIS 工作進程配置爲在 32 位模式 (SysWoW64) 下運行，此時它們本身消耗的內存更少，同時還允許操作系統比在 32 位環境中尋址更多的內存。

通過壓縮來降低帶寬

帶寬成本是運行面向 Internet 的數據中心的首要成本之一，這一點不足爲奇。此外，提供請求內容所需的帶寬是應用程序感知響應中的一個關鍵因素。

減少提供應用程序響應所需的帶寬的其中一種最有效方法是使用 HTTP 壓縮。它可以大幅減少響應的大小，對於容易壓縮的文本內容（如 HTML），通常可減小到原來的 1/10。其最大優勢在於所有桌面瀏覽器都支持它，並且與由於發送較少的數據而節省的延遲時間相比，桌面硬件的解壓縮開銷顯得無關緊要。此外由於壓縮是基於 HTTP 1.1 協議中所定義的內容編碼協商，因此啓用它對於不支持壓縮的客戶端而言是安全的 — 這些客戶端僅接收未壓縮版本的內容。

IIS 7.0 也包含其前身引入的以下兩個壓縮功能：靜態壓縮和動態壓縮。靜態壓縮會預壓縮靜態內容並將其保存在磁盤上，因此允許未來的請求無需壓縮開銷即可直接提供壓縮後的內容。動態壓縮會實時壓縮響應，因此可以壓縮由應用程序生成的響應。IIS 7.0 上的任意應用程序框架都可以利用動態壓縮 — 包括 ASP、ASP.NET 或 PHP。

動態壓縮通常並沒有令人望而卻步的 CPU 開銷，這一點讓很多人感到疑惑。實際上，動態壓縮一般只佔用繁忙服務器上不到 5% 的總 CPU 使用率。動態壓縮的部署不受限制，從而可以使應用程序工作負載節省儘可能多的帶寬。

可通過配置壓縮強度進一步優化壓縮開銷，從而實現所需的壓縮量與 CPU 開銷之比。但還不只這些 — 您還可以對應用程序進行配置以啓用壓縮內容緩存功能，這將可以通過提供已壓縮的內容來避免出現對命中緩存的壓縮開銷。請注意，ASP.NET 和 IIS 輸出緩存都進行了升級，現在既可以爲支持壓縮內容的客戶端緩存壓縮的內容，也可以處理來自需要未壓縮內容的客戶端的請求。

媒體比特率限制

隨着越來越多的站點提供媒體內容，導致許多企業的帶寬成本激增。更爲糟糕的是，由於發送到客戶端的媒體內容實際上根本沒有被用到，因而浪費了大量的媒體帶寬。爲什麼會發生這種情況？

想想上次瀏覽時您觀看在線視頻或視頻廣告的情形。您是否一直在觀看視頻直到結束？在瀏覽視頻網站時，用戶通常都是在觀看視頻的一部分後就轉到了另一個視頻或離開該頁面。但是，對於使用漸進式下載方式來提供視頻的 Web 服務器而言，它所發送的數據通常要遠遠多於這幾秒播放時間所需的數據。大部分數據根本就沒有使用到。

如果視頻的觀看時間平均只有 5 秒，但在這 5 秒鐘內提供（緩存）了 30 秒鐘的視頻數據，則您可能浪費了超過 80% 的帶寬！

一年前，爲了幫助一位使用測試版 IIS 7.0 的客戶解決這一問題，我編寫了一個帶寬限制模塊，它可以自動檢測視頻比特率並確保服務器以大致相同的速率向客戶端提供視頻。IIS 媒體團隊選擇了這一稱爲“比特率限制模塊”的模塊（請參閱圖 4），您可以在 iis.net 下載中心下載它 (iis.net/downloads/­?tabid=34&g=6&i=1640)。有關詳細信息，請參閱 Scott Guthrie 的博客（網址爲 go.microsoft.com/fwlink/?LinkId=122514）。

圖 4 比特率限制最小化帶寬使用率（單擊圖像可查看大圖）

“比特率限制模塊”會自動檢測最常見的視頻類型的編碼速率。您可以控制想要預發送到客戶端以消除初始緩存延遲的數據量（快速啓動）以及希望在提供內容時使用的編碼率百分比。您還可以配置許多其他選項（如最大帶寬和併發連接），並可以通過編程方式來控制模塊。

輸出緩存

一般而言，對於執行重複工作的應用程序而言，緩存是改善其性能的首選方法。與特定於應用程序的性能改善不同（它們通常需要花費大量的精力並不斷耗用應用程序的處理開銷），緩存可以免去重複請求相同內容的開銷。

在 IIS 7.0 之前，IIS 和 ASP.NET 都以 IIS 內核緩存和 ASP.NET 輸出緩存的形式提供緩存功能。IIS 內核緩存可提供最優的性能，但主要限於靜態內容。ASP.NET 輸出緩存是用於緩存動態內容的相當完善的解決方案，但其性能較低而且內存管理效率也不高。IIS 7.0 中新的輸出緩存彌合了 IIS 內核緩存和 ASP.NET 輸出緩存之間的溝壑。

IIS 7.0 輸出緩存可緩存任意應用程序（包括 ASP、ASP.NET、PHP 以及與 IIS 7.0 兼容的任何其他應用程序框架）中的動態內容。通過提供對內容可變性和過期的基本支持，這一新功能可緩存 IIS 內核緩存無法緩存的內容。並且，它允許針對滿足限制條件的內容使用內核緩存。

此外，對於不需要高級緩存功能（如緩存依賴關係或無效化）的 ASP.NET 內容，IIS 7.0 輸出緩存還提供了比 ASP.NET 輸出緩存性能更高的替代方案，但只能在 ASP.NET 輸出緩存中使用。

說到輸出緩存，最大的挑戰通常在於如何定義正確的內容過期、無效化和可變性策略，從而在維持所需的緩存準確性和時效性的同時實現高效的響應緩存。大多數情況下，只需正確配置緩存規則即可做到這一點，但有時則需要一些取決於運行時信息的更加複雜的策略。爲此，IIS 7.0 輸出緩存提供了可用於確保所需的緩存行爲的編程 API。這可以爲本來不會從緩存受益的內容釋放緩存性能潛力。此外，ASP.NET 集成管道可使非 ASP.NET 內容使用 ASP.NET 輸出緩存。

部署動態內容的輸出緩存可能會比較棘手，可能需要一個多層戰略來利用 IIS 7.0 平臺上各種緩存功能的效率和靈活性。這通常包括描述影響響應的多個參數，還包括首先定義過期和無效化戰略以維持緩存的最新狀態，然後再確定哪些緩存支持所需的語義。

儘管比較複雜，但還是值得爲此付出的。通過實現 IIS 7.0 輸出緩存，應用程序的總吞吐量可獲得多個數量級的改進，並且數據庫和業務層組件的負載也會相應減少。

將 ISAPI 代碼轉換成 IIS 7.0 模塊

IIS 7.0 引入了一個新的服務器 API，所有 IIS 7.0 模塊均以其作爲基礎。它取代了先前版本的 IIS 中使用的傳統 ISAPI 過濾器和 ISAPI 擴展 API。對於不需要支持先前版本的新模塊，新的 API 更易於使用、可幫助生成更可靠的服務器端代碼並且功能會更強大。

但是，IIS 7.0 爲此提供了一個選項，允許通過利用可選 IIS 7.0 模塊實現的兼容性層來支持現有的 ISAPI 過濾器和擴展。這將允許現有 ISAPI 組件無需重寫代碼即可在 IIS 7.0 上運行。

儘管使用現有的 ISAPI 投資可降低 IIS 7.0 遷移的門檻，但必須要充分考慮如何將傳統 ISAPI 代碼導入到新的 IIS 7.0 API 中。這樣做可免去 ISAPI 兼容性層的開銷，併產生 ISAPI 組件不具備的一些性能優勢。這些性能優勢可能會十分顯著，具體視 ISAPI 組件所執行工作的而定。例如，對於緩存配置元數據以及與站點、應用程序和 URL 相關聯的任何其他數據，IIS 7.0 模塊 API 都提供內置的支持，這可以明顯加快組件的內部操作速度。

此外，IIS 模塊 API 允許模塊異步執行長時間運行的操作，例如接收請求實體數據或發送響應。通過異步執行這些任務，服務器可以支持大量的併發客戶端（成千上萬），而不會由於請求線程數量的限制而最多隻能支持幾十個或最多幾百個併發客戶端。異步處理還可以消除處理應用程序中其他的請求和活動時帶來的影響、減少內存使用量以及得到更好的 CPU 利用率。

除了特定的性能影響模式外，原生 API 還可以使開發人員更加靈活地執行請求處理任務。它允許您改進服務器組件的設計，從而實現更高的效率。例如，對於一些在以前需要通配符 ISAPI 擴展和子請求執行的特定過濾任務，現在既可以在初始請求過程中在模塊中執行，也可以針對響應啓用 IIS 內核緩存。

這可能會需要一些原型設計和試驗以確定可以實現遷移好處最大化的最優設計。由於 ISAPI 和 IIS 7.0 模塊 API 之間存在基本體系結構的差異，因此直接移植路由不一定是正確的。要告訴大家的好消息是 IIS 7.0 模塊 API 比 ISAPI 使用起來更簡單，因此遷移難度會降低。

服務器可擴展性

IIS 7.0 提供端到端可的擴展性。它需要事先了解有關服務器操作的大量知識，儘管如此，它還是展示了改進特定於應用程序的性能的巨大潛力。在對服務器體系結構和請求處理有了一定的瞭解後，可利用此擴展性來設計自定義的性能解決方案，以適合您的應用程序、工作負載和硬件的需求。

這可以採用以自定義的實現來替換任意內置的 IIS 7.0 功能的形式。儘管 IIS 7.0 功能已經做了大量的優化和性能測試，但肯定無法針對每種可能的用途都進行優化。因此，您可以通過構建針對特定工作負載的優化來改善特定模塊的性能。例如，您可能希望重新實現目錄列表模塊來緩存內存中的目錄列表，而不是使用文件系統 API 來枚舉文件。

此外，可擴展性也可用於構建新的性能特性。此類功能的內置示例包括輸出緩存、壓縮模塊以及多種其他內部緩存。

要確定自定義性能特性的需求，您需要了解應用程序和工作負載的性能特性以及需要解決的瓶頸問題。IIS 7.0 爲性能分析提供了充足的診斷支持，可使需求和所需的可能設計功能更加清晰。

結束語

儘管 IIS 7.0 版本主要是一個功能版本，但它通過模塊化的體系結構、可配置性和新增的性能特性提供了顯著的性能改善。這些改善通過服務器合併和減少的帶寬成本爲企業成本節約鋪平了道路，並且可以提供更好的用戶體驗。

要正確利用這些改進，通常必須針對當前的應用程序平臺執行全面的分析並對 IIS 7.0 體系結構有充分的瞭解。如需有關本文中提及的 IIS 7.0 體系結構和功能的詳細信息，請訪問 iis.net。在 mvolo.com 中，我將撰寫更多的博客文章來介紹有關主動利用 IIS 7.0 來改進應用程序性能和降低運營成本的技術。

Mike Volodarsky 之前是 Microsoft IIS 團隊的一名項目經理。在過去的五年時間裏，他一直在推動 ASP.NET 2.0 和 IIS 7.0 核心功能的設計與開發。現在，他正在利用 IIS 7.0 和 Windows Server 2008 爲高性能 Web 場構建高級 Web 服務器技術。Mike 是《IIS 7.0 Resource Kit》一書的主要作者，並且經常爲《MSDN 雜誌》和 IIS 7.0 博客 (mvolo.com) 撰寫文章。