在IIS 7.0中的10大性能改進
邁克沃洛達爾斯基
概覽：
- 最小化您的應用程序足跡
- 降低帶寬成本
- 使用增強的緩存能力
當我遇到公司計劃採用IIS 7.0中，一個問題，不可避免地是移動到IIS 7.0服務器或應用程序的性能提高。該
答案是肯定的，但並不感到驚訝，當你沒有看到當你第一次將應用程序遷移到IIS 7.0的性能改進。
要理解這一點，你需要了解的性質的最新版本。IIS
6.0是一個工程旨在釋放完成三件事情：更強的安全性，可靠性更高，並提高了性能。相比之下，IIS 7.0是一個平臺發佈。其目的是將高品質的基礎Web服務器核心的模塊化和可擴展的平臺，其前身爲重點的現代部署和管理方案的支持。
實際上可能有很多的建築變化，新特點考慮Web服務器的性能產生負面影響，例如，一個關鍵的變化緊緊優化Web服務器的代碼路徑爆發成獨立的模塊，沒有得到特殊待遇Web服務器上。但是，由於很多IIS團隊績效工作，IIS
7.0仍然在其前身性能校驗和在某些方面超過它。我可以親口告訴你的工作在Web服務器上的核心和集成管道，實現這一目標需要很多別出心裁的設計和辛勤工作，在實施產品。
然而，IIS 7.0具有更高的潛力提供重大的性能改進和降低性能相關的成本爲您的服務器場，比任何其他的IIS釋放在過去。
你不一定要看到這些好處，僅僅通過遷移到IIS 7.0，但某些環境。Microsoft.com例如，在CPU效率提高了10％，（Microsoft.com團隊博客上，你可以找到完整的分析go.microsoft.com
/ fwlink的的/？LINKID = 122497）。您可能也注意到在特定的領域，包括安全套接字層（SSL）和Windows ®認證（現在都在內核中執行），在多核和多處理器機器的可擴展性更好的垂直明顯的改善。
儘管如此，真正的IIS 7.0馬力並不來自增量性能改進現有功能。相反，改進來自於新的功能，你必須積極利用。這些功能往往植根的靈活性和可擴展性的平臺和新的性能特性。在這篇文章中，我會告訴你10，你可以解鎖移動到IIS
7.0的性能改進的最重要來源。
精簡的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工作量大幅增加的吞吐量在最小配置結果。
.gif)
圖1 吞吐率靜態的工作量和ASP.NET三種不同的配置有100個併發客戶端的工作量（單擊圖像可查看大圖）
此外，您可能會看到在內存佔用和更高的現場密度的改進，尤其是在共享的託管環境或大量的工作進程的情況下，正在使用。這通常是獲得的少的DLL加載到每個進程和消除模塊的初始化以及請求處理過程中發生的任何內存分配。圖2顯示了相同的吞吐量測試中的內存使用（私有字節IIS工作進程）。雖然在這個例子中沒有明顯的改善，增幅分別符合預期，ASP.NET應用程序域的開銷相對高於拆除的模塊所提供的節省基線。
.gif)
圖2 內存使用率（專用字節）的靜態和ASP.NET三種不同的配置有100個併發客戶端的工作量（單擊圖像可查看大圖）
IIS 7.0提供額外的控制模塊在應用程序級別啓用，以及模塊的使用控制權的基礎上通過模塊的先決條件的工作量。雖然這需要先進的配置，它可以在多站點環境或應用程序，支持多種不同的工作負載提供額外的好處。
一個字謹慎：確定您需要的功能可能會非常棘手。你必須考慮的不僅是最小的功能來支持您的應用程序框架，而且任何附加功能，您的應用程序可能會間接依賴。例如，您的應用程序可能會依賴於特定的身份驗證方法，或依靠授權語義上提供的各種IIS功能，在這種情況下，去除那些可能會產生不利影響您的應用程序的安全性。同樣，您的應用程序可能會依靠一些模塊的功能或性能的影響，在這種情況下，移除它們可能會導致不正確的行爲或性能損失。
構建精益操作系統
的Windows Server ® 2008還提供了OS級別的組件，你可以用它來
進一步降低您的Web服務器的表面積。爲Windows Server 2008操作系統的服務器核心安裝選項是一個最小的，並且包含最小的一組核心OS子系統。服務器核心精益IIS
7.0 Web服務器是一個理想的環境。
但是，當評估服務器核心，要知道，一些限制可能會影響您的應用程序。服務器核心不提供Microsoft®。NET
Framework的支持，這意味着，沒有ASP.NET，沒有IIS NET的可擴展性，並沒有IIS管理器。另外，本地管理的任務將需要命令行工具，因爲沒有Microsoft管理控制檯（MMC）。從性能的角度來看，如果你已經正確利用的IIS組件化的，你可能看不到內存佔用或在Server
Core上運行的應用程序的工作量與一個完整的Windows Server實現吞吐量的差異。這是因爲IIS和您的應用程序的工作是相同的兩個平臺上。然而，有一個地方，在那裏你會看到一個不同：整體的足跡，無論是在服務器的磁盤空間和內存的使用方面。
作爲一個例子，圖3顯示的差異足跡後進行靜態的工作量測試一個完整的Windows
Server 2008的配置和服務器核心。雖然在這兩種情況下，IIS足跡幾乎是相同的，更低的總體OS足跡允許的工作量顯着更少的內存來支持服務器核心。較低的足跡實際上可能讓你更強大的硬件上部署應用程序的工作量，專注於應用程序的處理需求，而不是經營環境。當然，這使得服務器核心虛擬化環境的一個很好的選擇。
.gif)
圖3 完整的Windows Server 2008中對服務器核心後執行工作量靜態測試內存佔用（單擊圖像可查看大圖）
專業應用拓撲
當應用程序工作負載優化，可以分隔成不同的部分工作量。例如，而不是一個農場，30個相同的Web服務器上運行應用程序，你可以運行10個Web服務器，應用服務器，代理服務器進行緩存和壓縮。
有幾個原因爲什麼這種專業化工作。首先，許多應用程序工作負載的性能在很大程度上取決於各種共享資源，如內存，這可能是有爭議的多個部分之間的應用程序。對這些資源的競爭可以建立在其他的資源得到充分利用，防止每個服務器的瓶頸。分離的應用程序部分給出的部件準備好，否則有爭議的資源的訪問，從而導致更高的效率，在同一組硬件資源。
二，專業化可以使應用程序能夠實現更大的緩存局域性，從而提高了性能。這包括低級別的高速緩存，如虛擬內存的轉換後備緩衝器（TLB），文件系統緩存，和其他操作系統和應用程序緩存。另一個來源的局部性增益來從CPU。只集中在一個特定的應用程序的一部分，正在發生的平行活動的數量減少，可以降低應用程序的上下文切換的數量，並最大限度地提高由CPU執行的工作。
第三，專業化使特定工作負荷的優化，使每個部分的應用更高效地工作。許多這些優化是不可能的整個應用程序時，應用程序的不同部分的相互矛盾的需求，由於在同一服務器上支持。
一個共同的地方，發生這種情況是IIS和ASP.NET線程配置，這大大影響併發和間接影響許多應用的內存使用率，延遲和吞吐量。IIS靜態文件的工作量是非常異步的，需要一個高併發請求限制，但它生長在一個非常低的可用線程數。另一方面，許多的ASP.NET功能是同步的，長期封鎖，並要求高的線程數量，同時還有一些人要求較低的併發限制，以減少對內存的影響。通過分離靜態的工作量，擺脫到一個單獨的進程或服務器的請求處理管道，你可以優化的併發性，每一個人的工作量。
最後，專業化可以使更大的整體可擴展性，允許應用程序向外擴展離散工作量或彼此獨立的應用程序部分。這可以使應用程序的拓撲結構提供更高的容量和冗餘最需要它的地方，而不是要求你整個應用程序的應用同一模板。在這種模式下，專業的資源可能是物理服務器，虛擬服務器，甚至是在同一臺機器上的應用程序池。
當評估專業化的潛在好處在你的應用程序拓撲，開始在您的應用程序中找到處理或資源密集型的瓶頸。這些地區應該是第一候選人專業化隔離時，因爲他們可能提供了顯着的優化潛力，因爲他們將要求最高水平的規模。然後，評估是否把它們分離出來，使其餘的應用程序更有效運用資源。最後，您將需要評估的開銷帶來的孤立的應用程序組件的連接機制。
改進的應用程序支持
IIS 7.0通過FastCGI的應用程序框架，一個開放的協議所支持的許多開源應用框架，否則可能不支持穩定和高性能的原生整合IIS的擴展支持。的FastCGI與CGI（公共網關接口）協議，該協議已經得到了很長一段時間的IIS，在Windows平臺上提供性能大大改善。這主要是由於FastCGI的可重複使用的流程架構，消除了沉重的每個請求的進程創建開銷，從而使客戶能夠利用持續保持活着連接。
如果IIS使用CGI或其他機制支持的應用程序框架，你可能會達到提高性能（在某些情況下，穩定），通過移動FastCGI協議。
第一個應用程序框架，以利用這種支持是PHP。事實上，IIS團隊曾直接與Zend技術，以確保，IIS與PHP
FastCGI的實施工作，使性能改進在Windows上的PHP框架。（欲瞭解更多關於該項目中，在我的博客上看到張貼在go.microsoft.com
/ fwlink的的/？LINKID = 122509）。如果你有一個ASP或ASP.NET應用程序運行在IIS的Web服務器技術，包括混合， PHP或其他符合FastCGI的應用框架，使用其他技術，你可能會在IIS 7.0平臺，能夠整合這些應用程序。
移動到IIS 7.0和FastCGI PHP和其他應用程序框架將允許您利用各種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使得它可以提供較大數目的每個服務器上的應用程序比以前的一些內部測試中，高達100000網站在單個服務器上是可能的。這吸引了大量的網站和應用程序創建和配置的能力。
一個字謹慎：爲了實現高速的配置，你需要移動到新的配置API，爲老年人配置API無法實現它。此外，並非所有的IIS配置API都提供相同的性能特點，因此需要慎重的選擇，以確保高性能。如果有疑問，去利用新的IIS配置對象，包括Microsoft.Web.Administration命名空間，使用AppCmd.exe命令行工具，和配置IIS
COM對象從腳本訪問。NET或C + +代碼直接配置選項。
多少個站點，可以配置多少可以積極的區別在IIS架構是一個非常重要的區別，使用持久的應用程序和工作進程去處理請求。在這個模型中，活躍的應用程序服務器上的消耗更多的資源，但還提供了更好的持續性能，由於緩存和刪除的初始化成本。
因爲每個活躍的應用程序需要一定量的內存和一個單獨的工作進程（如果正在使用所推薦的應用程序隔離模型），活躍的應用程序，在很大程度上依賴於應用程序的內存佔用。因此，其工作進程（甚至可以共享相同的工作進程與其他靜態內容應用），而一個單一的應用程序，只提供靜態內容可能只需要3MB，一些動態的應用程序可能需要100MB以上的RAM，即使在低使用率。這使得IIS工作進程本身微不足道的內存開銷相比，應用程序的足跡時，確定可能的最大密度。
在典型的共享主機方案，它是經常可以看到什麼是所謂的80/20分配，要求的80％到20％的站點。這將導致在一個小的百分比的地盤的在任何給定的時間。要允許更多數量的活性位點，IIS
7.0提供了有效的生命週期管理。這可以幫助你從無效的應用程序，以便讓更積極的應用程序可以託管回收內存。
IIS 7.0引入了一個新的算法，稱爲動態閒置，閒置超時工作進程，主動調整的基礎上在服務器上的可用內存。由於內存變低，閒置的應用程序更迅速地去除，從而使更積極的應用程序可以託管。但是，如果內存可用，超時可以留大，以提供更好的性能和維護應用程序狀態。除了允許更多的應用程序激活，動態無功也有助於避免內存不足的情況，由於顛簸導致嚴重的性能退化。
要舉辦許多活躍的應用成爲可能，你也應該利用一個64位的操作系統，因爲這將允許操作系統，以解決超過4GB的內存。在此之上，你可以配置IIS工作進程運行在32位模式下（SYSWOW64），在那裏他們消耗更少的內存，同時允許自己的操作系統，以解決更多的內存比在32位環境中什麼是可能的。
從壓縮減少帶寬
這毫不奇怪，帶寬成本是一個面向Internet的數據中心運行成本的頂級。此外，提供所需的帶寬要求的內容感知應用程序的響應是一個關鍵因素。
需要將應用程序交付的反應，以減少帶寬的最有效的方法之一是使用HTTP壓縮。這可以減少響應有很大數量的大小，通常可以放大10時，適用於輕鬆地可壓縮的文本內容（如HTML）。最好的部分是，幾乎所有的桌面瀏覽器都支持它，和桌面硬件解壓成本相比是次要的發送更少的數據延遲儲蓄。因爲壓縮是基於HTTP
1.1協議中定義的內容編碼協商，使客戶端不支持，它是安全的壓縮這些客戶只接收未壓縮版本的內容。
IIS 7.0提供了兩種壓縮功能介紹它的前身：靜態壓縮和動態壓縮。靜態壓縮前壓縮靜態內容，並將其保存在磁盤上，從而使將來的請求提供壓縮的內容的情況下直接壓縮開銷。動態壓縮壓縮實時的響應，因此，可以由應用程序產生的響應的壓縮。在IIS
7.0上的任何應用程序框架，可以利用動態壓縮，包括ASP，ASP.NET或PHP。
儘管一個共同的神話，動態壓縮通常不會有一個令人望而卻步的CPU開銷。事實上，動態壓縮往往導致繁忙的服務器上的CPU利用率不到5％。可以部署動態壓縮有點寬鬆，允許任何應用程序工作負載的最大帶寬節省。
可進一步優化配置，以實現所需的壓縮對CPU開銷比的壓縮強度，壓縮開銷。但它不會停在那裏，你還可以配置你的應用程序啓用緩存壓縮的內容，已經壓縮的內容服務，消除了壓縮開銷緩存命中。請注意，ASP.NET和IIS輸出緩存已經升級與可選的能力，以支持它的客戶端緩存壓縮的內容，以及客戶需要壓縮內容的處理請求。
媒體比特率限制
隨着越來越多的網站提供媒體內容，對於許多企業的帶寬成本暴漲。更糟的是，有很大比例的媒體內容發送到客戶端的媒體帶寬被浪費，因爲從來沒有真正使用。爲什麼會出現這種情況呢？
想想你最後一次觀看在線視頻或瀏覽時看到視頻廣告。你看視頻的結束？這是常見的瀏覽視頻網站的用戶觀看移動到下一個視頻或離開頁面之前，只有部分視頻。但是，Web服務器通常會採用漸進式下載，提供視頻發送更多的數據比需要的那幾秒鐘的遊戲時間。大多數的數據永遠不會被使用。
如果您的視頻平均觀看時間只得到5秒，但交付（緩衝區）30秒，值得那些5秒的視頻數據，你可能會浪費80％以上的帶寬！
一年前，爲客戶解決這個問題，採用IIS 7.0的beta版本，我寫了帶寬限制模塊，自動檢測視頻比特率，並確保服務器到客戶端，在大致相同的速率提供視頻。IIS媒體團隊拿起這個模塊，這是被稱爲“比特率限制模塊（見圖4），可在下載中心iis.net（iis.net
/下載/ TABID = 34＆G = 6＆I = 1640）。您可以瞭解更多關於它的Scott
Guthrie的博客（在go.microsoft.com / fwlink的的/？LINKID
= 122514）。
.gif)
如圖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引入了一個新的服務器，所有的IIS 7.0模塊都是基於API。這取代了傳統的ISAPI篩選器和ISAPI擴展API使用以前版本的IIS。對於不需要支持以前版本的新模塊，新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，以提高應用程序的性能，並降低運營成本。
邁克沃洛達爾斯基是前微軟IIS團隊的項目經理。在過去的五年中，他一直在推動ASP.NET
2.0和IIS 7.0的核心功能的設計和開發。現在，他建立技術先進的Web服務器使用IIS 7.0和Windows Server 2008的高性能Web農場。邁克是主要領導者的書IIS
7.0 Resource Kit中，並寫入積極MSDN雜誌及他的IIS
7.0的博客，mvolo.com。