IIS 7.0: Top 10 Performance Improvements in IIS 7.0

發行項
08/18/2016

IIS 7.0

IIS 7.0 中的十大效能改進

Mike Volodarsky

綜覽：

盡量減少您的應用程式數量
降低頻寬成本
使用增強的快取功能

要了解原因，您必須認識最新版本的本質。IIS 6.0 是一種工程設計版本，目標是要完成三件事：:更強固的安全性、更高的可靠性，以及更佳的效能。相反地，IIS 7.0 則是一種平台版本。它的目的是要將它前版以高品質為基底的網頁伺服器核心，轉換成一個可擴充的模組化平台，以支援主要的現代部署和管理案例。

許多架構上的變更和新功能，實際上對網頁伺服器的效能可能會有負面影響 — 譬如，當中一項重大的變更，是把嚴密最佳化的網頁伺服器程式碼路徑，分成不受網頁伺服器特別對待的獨立模組。不過，還是要感謝 IIS 小組努力不懈地完成許多效能工作，使得 IIS 7.0 的效能不但與前版並駕齊驅，並且在某些方面表現更加出色。根據我個人投入網頁伺服器核心和整合式管線的工作經驗，要達成這樣的成效不僅需要具備相當精巧的設計才能，也必須下功夫在實作產品上。

儘管如此，說到提供大幅的效能改進和降低伺服器伺服陣列效能相關成本，IIS 7.0 所具備的潛能要比過去任何其他 IIS 版本大得多。

除了一些環境是例外，單是移轉至 IIS 7.0 並不一定可以看到這些成效。例如，Microsoft.com 在 CPU 效率方面就提高了 10% (您可以在 Microsoft.com 小組部落格上找到完整的分析，網址是 go.microsoft.com/fwlink/?LinkId=122497)。您也可能在某些方面發現到明顯的改進，包括安全通訊端層 (SSL) 和 Windows® 驗證 (兩者現在都在核心內執行)，以及在多核心和多處理器的電腦上看到更佳的垂直延展性。

話雖如此，IIS 7.0 真正的威力並不是來自對現有功能不斷進行的效能改進，而是來自您必須主動使用的新功能。這些功能通常深植於平台的彈性和可擴充的特性裡面，也可在新效能功能中窺見。在本文中，我將向您說明透過移轉至 IIS 7.0，您可以開啟的十大效能改進來源。

更精簡的網頁伺服器

部署精簡式 IIS 7.0 伺服器的能力是汲取自伺服器的模組化架構。幾乎它所有的網頁伺服器功能，都是實作成可以個別新增或移除的模組化元件。因此，您可以把任何對應用程式作業來說不必要的伺服器功能移除掉，來達成顯著的成效，包括大幅縮小受攻擊面，更小規模的作業支配，以及改進的效能等。

完整的 IIS 7.0 網頁伺服器功能組內含 44 個模組，包括原生 IIS 模組和 ASP.NET 模組，後者為整合式管線提供服務。這些模組提供如驗證 (Windows 驗證和摘要式驗證模組)、應用程式架構支援 (FastCGI 模組)、應用程式服務 (工作階段狀態模組)、安全性 (要求篩選模組)，以及效能 (輸出快取模組) 等服務。而最精簡的網頁伺服器 (只需要提供靜態內容)，只要兩個模組就可以運作了！

不必要的模組所產生的額外負荷可能相當明顯 — 例如，在要求記錄和失敗要求追蹤模組的情況下。而在不需要這類模組的環境中把它們移除，可產生較高的總輸送量，以及更快速的回應，因而減少伺服器工作負載的距第一位元組時間 (TTFB) 和距最末位元組時間 (TTLB) 度量。

[圖 1] 顯示當以完整的功能組、針對工作負載的預設功能組，以及針對工作負載所需的最精簡功能組設定時，對 HTML 檔案 (靜態工作負載) 與 Hello World ASP.NET 網頁 (ASP.NET 工作負載) 進行的簡單輸送量測試所產生的結果。雖然大多數非基本功能在「完整」設定中都已停用，但在「最精簡」設定中把它們完全移除，對靜態工作負載和 ASP.NET 工作負載兩者，仍舊增加了可觀的輸送量。

[圖 1] 靜態工作負載和 ASP.NET 工作負載在三種不同設定與 100 個並行用戶端下的輸送率 (按一下以放大影像)

除此之外，您還可能看到記憶體支配方面的改進，以及更高的網站密度，特別是在使用大量工作者處理序的共用主機環境或情況下。在每個處理序中載入更少的 DLL，並消除在模組初始化和要求處理期間發生的記憶體配置，通常就可以看到這樣的成效。[圖 2] 顯示相同輸送量測試中的記憶體使用量 (IIS 工作者處理序的專用位元組)。雖然改進的情況在本例中比較不明顯，但提升的程度還是有達到預期，因為 ASP.NET AppDomain 的負荷遠比移除模組所省下的基準量要高許多。

[圖 2] 靜態和 ASP.NET 工作負載在三種不同設定與 100 個並行用戶端下的記憶體使用量 (專用位元組) (按一下以放大影像)

IIS 7.0 還讓您控制要在應用程式層級啟用哪些模組，以及透過模組先決條件，根據工作負載來控制模組使用情況。雖然這需要進階設定才行，但它可在多網站的環境中，或是對支援多個不同工作負載的應用程式，提供額外的好處。

注意：判斷您所需的功能可能不容易。您不但必須考量支援應用程式架構所需的最基本功能，還必須考慮到應用程式可能間接需要仰賴的任何其他功能。例如，您的應用程式可能需要依賴特定的驗證方法，或仰賴不同 IIS 功能所提供的驗證語意，在這種情況下，若移除這些功能，可能會對應用程式的安全性產生負面的影響。同樣地，您的應用程式也可能有賴一些模組以獲得操作或效能上的成效，在這種情況下，若把它們移除掉，可能會產生行為不當或效能損失。

建置在精簡的 OS 上

Windows Server® 2008 另外還提供了 OS 層級的元件化，讓您用來進一步縮減網頁伺服器的表面。Server Core 是 Windows Server 2008 作業系統最基本的安裝選項，而且內含一組最精簡的核心 OS 子系統。Server Core 對於精簡式 IIS 7.0 網頁伺服器來說，是個理想的環境。

但是在評估 Server Core 時，要注意一些可能會影響您應用程式的限制。Server Core 並不提供 Microsoft® .NET Framework 支援，也就是說既沒有 ASP.NET，也沒有用於 IIS 的 .NET 擴充性，更沒有 IIS Manager。此外，因為沒有 Microsoft Management Console (MMC)，執行本機管理工作得使用命令列工具才行。從效能的觀點看來，如果您已經適當利用 IIS 元件化的優點，執行 Server Core 與完整 Windows Server 實作比起來，在記憶體支配或應用程式工作負載的輸送量方面，可能不會看到有多大的懸殊。這是因為 IIS 和您的應用程式所執行的工作在兩種平台上是一樣的。不過，您倒是會在一個地方看到差異：那就是伺服器的整體支配，就磁碟空間和記憶體使用量兩方面都有不同。

[圖 3] 舉例說明了在完整 Windows Server 2008 設定與在 Server Core 上執行靜態工作負載測試後，支配方面的差異。雖然 IIS 支配在兩種情況下實際上是一模一樣，但 Server Core 的整體 OS 支配規模較小，因此能夠以明顯更少的記憶體來支援工作負載。較小的支配規模也許實際上可以讓您把應用程式工作負載部署在能力較低的硬體上，而把焦點放在應用程式的處理需要上，而不是作業環境上。不用說，這使得 Server Core 成為虛擬化環境的絕佳選擇。

[圖 3] 完整 Windows Server 2008 與 Server Core 在執行靜態工作負載測試之後的記憶體支配比較 (按一下以放大影像)

專門化應用程式拓樸

將應用程式工作負載最佳化時，可把工作負載分隔成不同的部分。比方說，與其在 30 部相同的網頁伺服器伺服陣列上執行應用程式，不如在 10 部網頁伺服器、5 部應用程式伺服器和 3 部執行快取和壓縮的 Proxy 伺服器上執行應用程式。

這樣的專門化之所以可行的原因有好幾個。第一，許多應用程式工作負載的效能主要是看不同的共用資源而定，例如應用程式的不同組件之間可能會爭用的記憶體。爭用這些資源可能會造成瓶頸，而使其他資源無法完整利用每部伺服器。將應用程式的各組件相區隔，可讓組件迅速存取在其他情況下被爭用的資源，而在同一組硬體資源上達成更高的效率。

第二，專門化可讓應用程式達到更廣大的快取位置，進而提升效能。這包括低層級的快取，例如虛擬記憶體轉譯對應緩衝區 (TLB)、檔案系統快取，以及其他作業系統和應用程式快取。另一個取得位置的來源是 CPU。透過把焦點放在特定的應用程式組件上，來減少平行發生的活動數量，應用程式可藉此減少內容切換的數量，並充分發揮 CPU 所執行的工作。

第三，專門化可針對工作負載提供最佳化，讓應用程式的每個組件更有效地運作。如果整個應用程式是在同一部伺服器上受到支援，許多這些最佳化都會因為應用程式不同組件的需要彼此衝突而無法達成。

發生這種情況其中一個常見的地方是 IIS 和 ASP.NET 執行緒處理設定，這個設定會嚴重影響並行處理，並間接影響許多應用程式的記憶體使用量、延遲和輸送量。IIS 靜態檔案工作負載相當不同步，而且需要高並行處理要求限制，但它只需要非常少數的可用執行緒便可成功。另一方面，許多 ASP.NET 功能既是同步也處於長期封鎖狀態，而且需要高執行緒計數，而其他功能仍舊需要較低的並行處理限制來緩和對記憶體的衝擊。您可以透過分隔靜態工作負載，並把要求處理管線各部分分成不同的處理序或伺服器，把每個個別工作負載的並行處理能力最佳化。

最後，專門化還可讓應用程式向外擴充分散的工作負載或彼此獨立的應用程式組件，而達成更高的整體擴充性。這可讓應用程式拓樸在最需要的地方提供更高的容量和重複性，而不是要求您在整個應用程式套用相同的樣板。這種模型下的專門化資源，可以是實體伺服器、虛擬伺服器，甚或是相同電腦上的應用程式集區。

在評估將應用程式拓樸專門化可能的優點時，不妨先從找出應用程式當中的處理或耗用大量資源的瓶頸開始著手。這些地方應該是進行專門化的首選，因為它們在隔離時進行專門化的可能性相當高，而且也因為它們需要有最大的範圍進行向外擴充。接下來則評估將它們隔離是否可讓其餘的應用程式更有效地利用資源。最後需要評估的是，將隔離的應用程式元件結合在一起所需的連接機制，會產生多少額外的負荷。

改良過的應用程式支援

IIS 7.0 還透過 FastCGI 提供了對應用程式架構的延伸支援，這是許多開放原始碼應用程式架構所支援的開放通訊協定，若沒有此通訊協定，這些架構可能無法支援與 IIS 進行穩定且高效能的原生整合。與 IIS 長久以來支援的 CGI (通用閘道介面) 通訊協定不同，FastCGI 在 Windows 平台上提供了更佳的效能。這都要歸功於 FastCGI 的可重複使用處理序架構，這種架構消除了依要求建立處理序的沉重負擔，而讓用戶端可以利用持續作用的連線。

如果您使用 CGI 或其他機制在 IIS 上支援應用程式架構，那麼移轉至 FastCGI 通訊協定也許可達成更佳的效能 (在某些情況下，還能達成穩定性)。

第一個利用這項支援的應用程式架構，是 PHP。事實上，IIS 小組已經與 Zend Technologies 直接合作，確定 IIS FastCGI 實作能與 PHP 順利搭配運作，並且能在 Windows 上提升 PHP 架構內的效能 (如需此專案的詳細資訊，請參閱我部落格上的文章，網址是 go.microsoft.com/fwlink/?LinkId=122509)。如果您混用各種網頁伺服器技術，包括在 IIS 上執行的 ASP 或 ASP.NET 應用程式，以及採用其他技術的 PHP 或其他 FastCGI 相容應用程式架構，也許可以在 IIS 7.0 平台上整合這些應用程式。

將 PHP 和其他應用程式架構移到 IIS 7.0 和 FastCGI，可讓您充分利用各種 IIS 7.0 功能，包括 ASP.NET 整合式管線。此舉提供了一個非常便利的選擇，即使不將它們轉換成 ASP.NET，也可以利用 ASP.NET 服務強化應用程式架構。而且這也讓使用不同架構的應用程式得以彼此協同作業。若想瞭解如何利用這種方式來強化現有應用程式的功能，以及在不變更任何程式碼下提升效能，請參閱我在《MSDN® Magazine》發表的＜使用整合式 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 命令列工具，以及從指令碼、.NET 或 C++ 程式碼存取的 IIS COM 設定物件。

可以佈建多少網站，以及可以使用多少網站兩者之間，在 IIS 架構上存在著相當重要的差別，此架構是使用持續的應用程式和工作者處理序來執行要求處理。在這種模型下，作用中應用程式會在伺服器上耗用較多的資源，但也因為快取而且不用初始化成本的緣故，因而提供持久的效能。

因為每個作用中應用程式都需要特定的記憶體量以及個別的工作者處理序 (如果採用建議的應用程式隔離模型的話)，所以作用中應用程式的數目主要要視應用程式記憶體支配而定。因此，只提供靜態內容的單一應用程式，它的工作者處理序可能只需要 3MB (而且甚至可以與其他靜態內容應用程式共用相同的工作者處理序)，反之有些動態應用程式即使使用量很低，還可能需要 100MB 或以上的 RAM。這在定義最大密度時，使得 IIS 工作者處理序本身的記憶體負荷與應用程式的使用量比起來，顯得微不足道。

在典型的共用主機情況下，使用所謂的 80/20 分配是很常見的，也就是 80% 的要求送往 20% 的網站。因此不管在任何時間，只會有一小部分百分比的網站處於作用狀態。為了允許有更多的作用中網站，IIS 7.0 提供了作用存留期管理。這可幫助您從非作用中應用程式取回記憶體，以便裝載更多作用中應用程式。

IIS 7.0 引進了一種全新的演算法，稱為動態閒置，它會根據伺服器上可用的記憶體，主動調整工作者處理序的閒置逾時。隨著記憶體越少，更能迅速移除閒置應用程式，從而允許裝載更多作用中應用程式。然而，如果有記憶體可用，逾時也會保持較長的時間，以提供更佳的效能並維持應用程式狀態。除了允許更多應用程式保持作用狀態外，動態閒置還有助於避免發生低記憶體的狀況，這種狀況會因濫用而導致嚴重的效能折損。

為了盡可能裝載最多的作用中應用程式，您也應該利用 64 位元作業系統，因為這可讓 OS 處理 4GB 以上的記憶體。除此之外，您還可以將 IIS 工作者處理序設定在 32 位元模式 (SysWoW64) 中執行，在這種模式中，它們本身會耗用較少的記憶體，而允許 OS 處理比在 32 位元環境中還多的記憶體。

透過壓縮減少頻寬

說頻寬成本是執行網際網路面向的資料中心最高的成本之一，一點也不為過。此外，傳遞要求的內容所需的頻寬，也是觀察應用程式回應能力的關鍵要素。

要減少傳遞應用程式回應所需的頻寬，最有效的方法之一，就是使用 HTTP 壓縮。這可大幅縮小回應的大小，並且在套用到可輕易壓縮的文字內容 (例如 HTML) 時，可減小 10 分之一的大小。最棒的是，實際上所有的桌上型瀏覽器都支援它，而桌上型硬體上的解壓縮成本，比起傳送更少資料所省下的延遲要來得低。而且由於壓縮是根據 HTTP 1.1 通訊協定中定義的內容編碼交涉進行的，因此對於不支援壓縮的用戶端來說啟用它很安全 — 這些用戶端只會接收到未壓縮版本的內容。

IIS 7.0 提供兩種由它前版所提供的壓縮功能：靜態壓縮和動態壓縮。靜態壓縮會預先壓縮靜態內容，並將它儲存到磁碟上，從而允許未來的要求在沒有額外的壓縮負荷下，直接提供已壓縮的內容。動態壓縮則會即時壓縮回應，因此可壓縮由應用程式所產生的回應。IIS 7.0 上的任何應用程式架構皆可利用動態壓縮 — 包括 ASP、ASP.NET 或 PHP。

儘管普遍存在一種迷思，動態壓縮通常沒有過於沉重的 CPU 負荷。事實上，動態壓縮在忙碌的伺服器上，常常花不到 5% 的總 CPU 使用率。您多少可以自由地部署動態壓縮，以盡量節省頻寬，將它用於任何應用程式工作負載。

您還可以設定壓縮強度，以達到所要的壓縮與 CPU 負荷比率，進一步將壓縮負荷最佳化。好處還不只如此，您也可以設定應用程式來啟用壓縮內容的快取，這可透過提供已經壓縮的內容來消除壓縮負荷對快取的衝擊。要注意的是，ASP.NET 和 IIS 輸出兩種快取都已經過選擇性功能的升級，為支援它的用戶端快取壓縮內容，以及處理需要未壓縮內容的用戶端所發出的要求。

媒體位元速率節流

隨著提供媒體內容的網站數量不斷增加，許多企業的頻寬成本也跟著暴漲。更糟的是，因為傳送給用戶端的媒體內容都沒有真正用到，而浪費了高百分比的媒體頻寬。為什麼會這樣呢？

想想看您上次看線上影片時，或在上網時看到影片，您有把整段影片看完嗎？瀏覽影片網站的使用者常常只看了部分影片就移往下一段影片或離開網頁。不過，利用漸進下載來提供影片的網頁伺服器，一般傳遞的資料遠比只播放幾秒鐘的時間所需的資料還多。而大部分的資料根本沒用到。

如果您的影片平均只得到 5 秒的觀賞時間，卻在這 5 秒內傳遞 (緩衝) 值 30 秒的視訊資料，您很有可能浪費了 80% 以上的頻寬呢！

一年前，為了幫採用 IIS 7.0 Beta 測試版的客戶解決這個問題，我寫了一個頻寬節流模組，這個模組會自動偵測視訊位元速率，並且確保伺服器以大致上相同的速率傳遞視訊給用戶端。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 核心快取快取的內容實作快取。然而，它還是可以對符合限制條件的內容使用核心快取。

此外，IIS 7.0 輸出快取還針對不需要用到只在 ASP.NET 輸出快取中有提供的進階快取功能 (例如快取相依性或失效) 的 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 也可以讓您透過相容性層支援現有的 ISAPI 篩選器和延伸模組，而這個相容性層是透過選擇性的 IIS 7.0 模組實作而成。這麼一來，現有的 ISAPI 元件不需經過重寫，就可以在 IIS 7.0 上運作了。

縱然使用現有的 ISAPI 投資可減輕 IIS 7.0 移轉的障礙，但您還是應該慎重考慮將舊版 ISAPI 程式碼移植到全新的 IIS 7.0 API。這樣不但可以消弭 ISAPI 相容性層的額外負荷，更能享受 ISAPI 元件所沒有的效能效益。根據 ISAPI 元件所執行的工作而定，這些效能效益可能相當可觀。譬如，IIS 7.0 模組 API 提供了對快取設定中繼資料和其他與網站、應用程式和 URL 相關任意資料的內建支援，明顯加速元件的內部作業。

除此之外，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 伺服陣列的進階網頁伺服器技術。Mike 是《IIS 7.0 Resource Kit》一書的主要作者，並積極為《MSDN Magazine》和他的 IIS 7.0 部落格 (mvolo.com) 撰文。