Microsoft.com Moves to x64 Version of Windows

技術性白皮書

本頁內容

執行摘要
介紹
Microsoft.com 遷移至 64 位元網頁伺服器
在 32 位元平台 (x86) 上的歷史挑戰
Windows 64 位元版本的潛在優勢
採用 – 策略和方法
優點
最佳實作
結論

執行摘要

在 2004 年 3 月，大約是正式發行 Microsoft® Windows Server™ 2003 x64 Edition 的一年前，Microsoft.com 決定針對在 x64 為主的硬體平台上建立的伺服器之實作評估其優勢，方法是在實際執行 www.microsoft.com 網頁伺服器上執行該作業系統的發行前版本。到 2005 年 4 月，Microsoft.com 已有 100% 的實際執行網頁伺服器是在 x64 為主的硬體與作業系統平台上執行。

32 位元版本的 Microsoft Windows® 固有的虛擬記憶體位址空間限制已逐漸增加，導致 Microsoft.com 作業小組在應用程式穩定性與疑難排解方面的挑戰。透過 64 位元版本的 Windows，應用程式的虛擬記憶體位址空間已大幅增加。這個重要功能與可輕鬆執行具有高效能的 32 位元應用程式之結合，已解決過去已經成為 Microsoft.com 的頭號問題：記憶體爭用。x64 為主的硬體平台可以原始地執行 32 位元的程式碼，與設定相同的 32 位元硬體有差不多相同的效能等級，而且在 Windows x64 版本中的 32 位元環境也可以執行 32 位元的應用程式，並且不需要任何的程式碼修改，這使得平台遷移幾乎沒有中斷。

升級至 Windows x64 版所產生的平台已大幅增加 Microsoft.com 網頁伺服器的應用程式與 Web 服務回收之間的平均時間，因而增加了整體網站的可用性。更令人印象深刻的是，伺服器的 CPU 負載減少了 50%，而且某些應用程式的網頁回應時間速度快了多達 15 倍之多。

本白皮書的目的就是要分享根據 Microsoft.com x64 為主的網頁伺服器解決方案的架構、設計和部署之考量與經驗，以證明關於高可用性、高效能網站之目前 Microsoft 產品的價值。本文簡短地討論 Microsoft.com 上 Web 平台的評估、x64 為主的平台解決了作業小組在 32 位元平台所遭遇到的挑戰、遷移與部署策略，以及產生的基礎結構架構。

如 Internet Information Services (IIS) version 6.0、Microsoft ASP.NET 與 Microsoft .NET Framework 以及相關的技術，例如：網路負載平衡 (NLB) 與 Microsoft SQL Server™ 2000。組織可以運用本文所描述的許多原則與技術以規劃 Web 平台的升級。同樣地，組織可以將 x64 為主的網頁伺服器基礎結構的設計考量套用至大部分任何企業規模的 IT 環境。不過，本文是根據 Microsoft.com 作業小組的經驗與建議做為早期採用者。它並不是要做為程序上的指南。每個企業環境都有獨特的環境，因此，每個組織都應該修改從本文所得知的規劃與觀念以符合其特定需求。

注意：* *基於安全性考量，在本文中所使用的樹系、網域、內部資源、組織以及內部開發的安全性檔案名稱之範例名稱，不代表 Microsoft 中所使用的真實資源名稱，而且僅供說明之用。

介紹

Microsoft 公司網站 Microsoft.com 是網際網路上最大且瀏覽最頻繁的網站之一，被評比為任何指定一天中第四或第五最忙碌的網站。整個 Microsoft.com 企業橫跨三個資料中心，並且由數以千計的伺服器所組成，使用超過 1,000 個資料庫、支援數千種 Web 應用程式，換言之，www.microsoft.com 每天平均有超過 1 千 3 百萬的唯一使用者與 7 千萬的網頁檢視。這些使用者平均每秒執行 10,000 個連線，並且在總共 80 台的網頁伺服器上維護平均 300,000 個同時連線。

Microsoft.com 也運用內容提供網路夥伴來延伸其觸角及可用性，並透過全球性地負載平衡與快取內容來改善效能。

除了支援數千台的實際執行伺服器之外，作業小組還支援數各種環境中數百台的非實際執行伺服器，從開發到預先生產或接移，以及數十部支援該網站的基礎結構伺服器。

如下表所示，Microsoft.com 達到的美國網際網路使用者總數超越所有的公司網站，並從 2004 年持續成長了 6.9%。

表格 1. 企業網站到達排名

排名	公司	唯一使用者	到達 百分比
1	Microsoft	5 千 4 百萬	36.3
29	Apple	1 千 3 百萬	8.9
31	Netscape	1 千 2 百 90 萬	8.7
183	Sony	4 百 20 萬	2.8
334	IBM	2 百 60 萬	1.8
469	Sun	2 百萬	1.4

作業小組的任務是負責讓 Microsoft.com 達到網際網路上的最高可用性，同時又能展示 Microsoft 技術。作業小組已經開發一個策略，以做為許多 Microsoft 產品的早期採用者，並提供珍貴的意見反應給產品群組，同時又能與 Microsoft 客戶分享其最佳實作。

過去三年來，根據由電子商務效能管理服務的世界級領導者 Keynote 所評估的網站可用性，Microsoft.com 已成為網際網路上評比第一名的網站。透過其 Keynote Global 35 監控服務，Keynote 定期驗證世界上 35 個地點的整個網頁及其所有可用的元件來評估其可用性。如果在網頁上的單一映像無法從任何測試的地點使用，Keynote 就會將網站視為在該間隔時間失敗的網站。下表顯示 Microsoft.com 與 Keynote Global 35 服務也監控之其他名列前茅的產業網站的比較。如需更多關於 Keynote Global 35 監控服務的資訊，可以參考 IT Showcase 監控案例研究與 Microsoft.com 疑難排解，請造訪 https://www.microsoft.com/technet/itshowcase/content/mscomserverconfig_note.mspx。

表格 2. 網站可用性排名

排名	網站	可用性 百分比
1	Microsoft.com	99.82
2	Windows Update	99.81
3	Google	99.71
4	IBM	99.70
5	AOL	99.69
6	Dell	98.63
8	Oracle	84.06

雖然 Microsoft.com 網站持續地成長，並且在 32 位元硬體與作業系統平台上達到空前的可用性與效能等級，但是 32 位元平台固有的記憶體限制讓作業小組面臨特殊的挑戰。這些挑戰需要經常介入，這使得作業小組很難疑難排解和偵錯 Web 應用程式。

Microsoft.com 遷移至 64 位元網頁伺服器

由於虛擬記憶體定址空間的增加，使得 Microsoft.com 作業小組有興趣評估在 64 位元版本的 Windows 上執行 www.microsoft.com 網頁伺服器的潛在優勢。

在 32 位元平台 (x86) 上的歷史挑戰

Microsoft.com 作業小組會定期監控和分析廣大陣容的整個網站之效能評估，以及支援網站的個別伺服器。尤其是，作業小組對於在 x86 平台上的伺服器效能找到的最大瓶頸是網頁伺服器上的記憶體爭用。

在 32 位元版本的 Windows 中，總虛擬記憶體位址空間為 4 GB。作業系統預設會為核心模式處理序保留該空間的 2 GB，並將應用程式限制為虛擬記憶體位址空間剩餘的 2 GB。當應用程式虛擬記憶體空間變成過度認可或是分散時，應用程式可能發生錯誤或是效能降低，而且可能會停止正常運作。在 IIS 6.0 中，當這個情況發生時，必須回收應用程式集區，使應用程式得以回到正常的效能等級。

若為 Microsoft .NET 應用程式，Common Language Runtime (CLR) 會在虛擬記憶體位址空間中配置大型連續區塊的記憶體。CLR 會透過稱為記憶體回收的程序來管理其堆積內的分散程度，這將會定期壓縮其記憶體區域以便在推積中將可用的記憶體維持成連續的區塊。經過一段時間後，就會發生記憶體分散，這是因為 CLR 持續配置和釋放記憶體，使得一開始大型連續的可用記憶體區塊分成許多較小的可用記憶體區塊。受管理的 CLR 堆積外面的記憶體受限於這個類型的分散。又加上因為記憶體流失、高數量的已載入組件以及 ASP.NET 快取的過度使用，而持續增加記憶體的耗用，使得 CLR 的可用虛擬記憶體大幅減少。

因為記憶體使用持續增加，而且特別是當它接近可用的上限時，記憶體回收行程必須更努力地滿足配置要求。因為記憶體回收行程是在提高執行緒優先順序層級執行，而且當相同的伺服器上有多個應用程式達到其虛擬記憶體限制時，過度的記憶體回收行程活動就有可能導致隨著時間的經過，而逐漸增加整個伺服器沒有回應的期間。

透過使用 boot.ini 檔案中的 /3GB 參數，您可以設定 Windows 32 位元版本以配置 3 GB 的記憶體給應用程式。不過，這個動作將會減少為核心模式處理序配置的記憶體數量。在高流量的網頁伺服器案例中，這個動作可能會產生災難性的結果。高流量的網頁伺服器須建立和維護數以千計的並行 TCP 網路連線，每個都需要配置核心記憶體資源。雖然使用 /3GB 參數會提供 1 GB 的額外虛擬記憶體給應用程式，但是它會將 TCP 連線管理等核心模式處理序限制為 1 GB 的虛擬記憶體。具體而言，作業小組發現當使用 /3 GB 參數時網路堆疊會經常失敗，特別是稱為 SYN 攻擊的 TCP 連線要求攻擊案例。

在 Microsoft Windows 2000 與 IIS version 5.0 中，所有的網站與應用程式都會在單一共用應用程式環境中執行，該環境具有虛擬記憶體位址空間的單一 2 GB 配置。這表示任何執行很差的單一應用程式都有可能造成其他應用程式執行很差，或是造成伺服器上的整個 Web 服務停止運作。像這樣情況的解決方案就是回收 IIS 或是重新啟動伺服器以重頭開始 2 GB 的虛擬記憶體配置。這個動作將會造成不希望發生的結果，即在回收的持續時間從服務移除網頁伺服器，而且它會清除伺服器上任何應用程式之前建立的快取。

Windows Server 2003 與 IIS 6.0 導入網站管理員功能，以建立除了網站預設應用程式集區之外的自訂應用程式集區。每個應用程式集區會在自己的虛擬記憶體位址空間之隔離配置中，繁衍專用的工作者執行緒。透過使用應用程式集區，就可以將應用程式個別隔離或是併入邏輯群組中。例如，可以將重要的應用程式放在它自己的應用程式集區，以限制另一個應用程式不利地影響其效能的可能性。相反地，可以將已知執行差的應用程式放在專用的應用程式集區，以限制它將不利地影響另一個應用程式效能的可能性。

當特定的應用程式集區未正常運作或是已達到強制重新啟動的指定閾值時，只會將個別的應用程式或應用程式群組設成離線或重新啟動。最重要的是，應用程式集區回收動作是由作業系統以適宜的方式來執行。例如，在應用程式集區離線之前，會將要求排入佇列，同時會產生該應用程式集區的新處理序，以便在其上線時服務所有後續的要求。

注意：* *系統管理員也可以設定應用程式集區，以根據時間間隔或記憶體使用閾值來重新啟動。預設值會讓應用程式集區每 12 小時自動重新啟動。Microsoft.com 作業小組偏好使用 2 GB 的虛擬記憶體閾值設定，而不是時間間隔。

在指定網頁伺服器上應該建立的應用程式集區之數目有實際的限制。在 Microsoft.com，它決定在 32 位元伺服器上最佳的應用程式集區數目是 12。Microsoft.com 作業小組將已經歷完整 Software Development Life Cycle (SDLC) 的應用程式視為信任的程式碼。所有其他的應用程式 (包括許多來自合作夥伴組織的應用程式) 都被視為不信任的程式碼。Microsoft.com 作業小組透過在應用程式集區中將類似程式碼群組在一起，以便將信任程式碼與不信任程式碼分開。有些重要的應用程式有記憶體流失等已知問題，可能會取得專用的應用程式集區。不過，在達到伺服器上應用程式集區的最佳數目之後，將應用程式隔離在它自己的應用程式集區不再是一個選項，所以大部分的應用程式都會在共用的應用程式集區中。一般而言，大部分有問題的應用程式都在不受信任的應用程式集區中，但是如果有應用程式導致在不受信任的應用程式集區中的其他應用程式當機，就會將該應用程式禁止在該位置中，直到開發人員修復它為止。

注意：* *Web 應用程式開發人員可以使用新發行的 Debug Diagnostic Tool (包括在 IIS 診斷工具組中) 以及如「應用程式中心測試」等應用程式壓力測試工具 (包括在 Microsoft Visual Studio® .NET 中)，以協助他們診斷 IIS 中的記憶體流失。

雖然能夠使用隔離的記憶體保護以建立獨立的應用程式集區，已對 Microsoft.com 產生極大的優勢，但是每個應用程式集區仍然受限於 2 GB 的虛擬記憶體限制，而且記憶體回收間隔會逐漸變得更短。許多應用程式或應用程式群組需要 2 GB 以上的虛擬憶體，以為延長的期間以最佳的效能層級來操作。由於有 2 GB 的記憶體限制，因此要判斷應用程式實際上是否需要 2 GB 以上才能正常運作，或是該應用程式是否有記憶體流失，將會非常困難。即使能夠為自動化的應用程式集區重新啟動設定閾值，如果它們經常發生，對於伺服器將會是很嚴重的效能打擊。隨著複雜的 ASP.NET 應用程式對於資源需求的增加，Microsoft.com 的有些應用程式集區每隔五分鐘就回收一次。

注意：* *當應用程式集區重新啟動時，它必須為應用程式重建快取元素。通常這對效能有很大的影響。系統管理員可以設定「應用程式」集區重新啟動行為以孤立舊的處理序，這樣就可以偵錯該程序，但是此方法有效能問題，而且可能需要系統管理員暫時將伺服器離線。

隨著數以百計逐漸增加的複雜應用程式在 Microsoft.com 網頁伺服器上執行，因為虛擬記憶體限制的原故而產生的挑戰，只會持續地增加。

64 位元版本的 Windows 潛在的優勢

32 位元版本的 Windows 與 64 位元版本的 Windows 之間主要的差異之一，就是額外位元所提供的大幅增加的虛擬記憶體空間位址。x64 為主平台的 Windows 使用 43 位元來定址虛擬記憶體空間，這提供了核心 8 TB 的可定址記憶體，並為 64 位元的使用者模式處理序保留其他 8 TB。因為作業系統再也不需要與核心模式作業共用 32 位元的定址空間，32 位元應用程式的虛擬記憶體位址空間也從 2 GB 增加到 4 GB，這是總共可用的 32 位元記憶體位址空間。這些增加了可用的記憶體，從而完全消除了 64 位元應用程式的實際記憶體限制，同時還潛在地大幅增加 32 位元應用程式的優勢。 下列表格摘要了 32 位元和 64 位元的Windows 之間的記憶體限制的差異。

表格 3. 一般記憶體限制

現況	32 位元	64 位元
總虛擬位址空間 (單一處理器為基礎)	4 GB	16 TB
每一 32 位元處理器虛擬位址空間	2 GB	2 GB
每一 32 位元處理器虛擬位址空間 (具 /3 GB 切換)	3 GB	N/A
每一 32 位元處理器虛擬位址空間 (具 /LARGEADDRESSAWARE 切換)	N/A	4 GB
每一 64 位元處理器虛擬位址空間	N/A	8 TB

注意：* 若是 32 位元應用程式要利用較大的 4 GB 位址空間，則必須在編譯應用程式時提供 /LARGEADDRESSAWARE *旗標給編譯器。當指示在 Microsoft Windows-32-bit-On-Windows-64-bit 或是 WoW64 環境中執行工作者處理序時，預設會以此旗標設定 IIS 6.0。

Microsoft 在 2001 年推出 Windows 2000 64 位元版本的 Windows。第一個版本是針對在 Intel Itanium 硬體平台 (又稱為 Itanium) 上執行所特別設計。雖然 64 位元的作業系統以及適用於 Itanium 的後續 Windows Server 2003 版本，為應用程式的虛擬記憶體位址空間提供大幅增加的限制，不過該平台大部分是針對並適用於 64 位元應用程式。與今日許多 Windows Server 應用程式相同的是，Microsoft.com Web 應用程式是針對在 32 位元環境中執行所設計。一般而言，32 位元的應用程式在 Itanium 平台上無法像在原生 32 位元平台上有良好的效能。此外，相較於 x86 平台伺服器，Itanium 硬體需要相當大的投資。

自從 Itanium 平台發行後，Intel 與 AMD 已經根據 32 位元的暫存器與 64 位元的延伸模組，開發了更經濟的 64 位元相容 CPU，又稱為 x64 為主的平台 (Intel 將其晶片稱為 EM64T)。此設計允許在 x64 為主的伺服器上部署 32 位元或是 64 位元的作業系統。此外，對於 x64 版本的 Windows Server 2003，可以在 WoW64 環境中執行 32 位元的應用程式，這可讓它們使用 32 位元的暫存器以原生方式來執行，而且對效能的影響微乎其微。事實上，在 WoW64 中執行的 32 位元應用程式以及在 x64 為主的硬體上執行的 32 位元版本之 Windows，通常較同樣設定的 32 位元伺服器較為優越。Microsoft.com 作業小組發現在 x64 為主的硬體上執行 32 位元應用程式時，沒有負面的效能影響。

能夠執行 64 位元的作業系統並克服 32 位元作業系統的虛擬記憶體限制，並為 32 位元應用程式提供同等或較佳的效能，而不需修改程式碼，是相當有希望的。結合可能較低的硬體成本，x64 為主的硬體，與作業系統平台與，可用較低的價格提供增加的效能。

從潛在優勢的觀點來看，在 2004 年 3 月，大約是正式發行 Windows Server 2003 x64 為主的版本的一年前，Microsoft.com 決定針對在 x64 為主的硬體平台上建立的伺服器之實作評估其優勢，即進行概念證明 (POC) 測試，然後在實際執行 Microsoft.com 伺服器上執行該作業系統的發行前版本。

採用 – 策略和方法

在完全地測試新平台之前，作業小組必須為 x64 為主的伺服器開發標準組態，類似於 32 位元伺服器的現有組態。

Microsoft.com 如何開始遷移至 x64 的平台

www.microsoft.com 網站是由 80 台相同設定的網頁伺服器來服務，它們是在每個都使用 NLB 的 8 台伺服器之 10 個負載平衡的叢集中。由於有這樣高度的備援，作業小組就可以從特定的 NLB 叢集中新增或移除伺服器，而不會影響整個網站的可用性或效能。透過使用與現有伺服器之一相同的內容、應用程式和設定來設定 x64 為主的伺服器，作業小組可以將新伺服器新增至現有的實際執行叢集並監控其效能。

注意：* *系統管理員通常會建立 IP 負載平衡的 NLB 叢集，讓所有的叢集成員主動服務一群有相當靜態的內容與資料且設定相同的伺服器之要求。不像使用 Microsoft Cluster Service 的錯誤後移轉叢集，在 NLB 叢集中的伺服器之間不需要共用的儲存體。

Microsoft.com 作業小組從標準的作業系統映像建立所有的 Microsoft.com 伺服器，然後經由套用組態指令碼將伺服器設定為網頁伺服器，以確保小組能以相同的方式來建立和設定所有的伺服器。如需更多關於 Microsoft.com 伺服器組態，可以參考在IT Microsoft.com 標準伺服器組態的 IT Showcase，請造訪： https://www.microsoft.com/technet/itshowcase/content/mscomserverconfig_note.mspx。

為了評估 x64 為主的伺服器，作業小組建立了標準的網頁伺服器組建，包括基本作業系統以及已撰寫指令碼的網頁伺服器組態。x64 為主作業系統的組建 1171 是作業小組選擇部署的第一個版本。作業小組接著可以使用 AMD 提供的硬體以及新建立的標準伺服器組建來執行 POC 測試。作業小組會將 POC 伺服器設定成下表所述。

表格 4. x64 測試伺服器組態

元件	組態
處理器	四顆 1.6 GHz AMD64 Opteron CPU
隨機存取記憶體	8 GB
硬碟空間	50 GB (作業系統)，136 GB (資料)，50 GB (記錄檔)
網路	Gigabit fiber (前端)，100-MB copper (後端)
作業系統	Windows Server 2003 x64 Edition Build 1171

基本作業系統組態包括所有需要部署到資料中心的系統工具與應用程式。x64 版本的 Windows 需要硬體裝置的特定驅動程式以及任何包括核心模式存取的工具或應用程式 (如防毒軟體)。作業小組必須取得和測試適當的驅動程式以確認功能。在設定基本作業系統映像並變得穩定後，作業小組會在測試實驗室中在新平台上遞增地測試各種應用程式。這個測試需要投入相當多的時間與努力，因為每個設定相同的 Microsoft.com 網頁伺服器裝載 350 個虛擬根目錄、190 個 IIS Web 應用程式以及 12 個應用程式集區。

為了與 POC 比較，Microsoft.com 作業小組購買了 x64 為主的硬體以取代 32 位元伺服器。如上一節所述，x64 為主的平台可以執行 32 位元或是 64 位元版本的 Windows。起初，作業小組使用標準 32 位元作業系統網頁伺服器組態來建立新的 x64 為主的伺服器，並將它部署到生產環境。此時，作業小組也將 NLB 叢集中的伺服器數目從 6 增加到 8，以變更NLB 叢集的架構。

一完成 POC 實驗室測試，作業小組就會將 POC 伺服器新增至其中一個實際執行 NLB 叢集。作業小組在處理即時流量時觀察伺服器，因為需要最後驗證，才能繼續完全遷移到 x64 為主的平台。作業小組接著將 NLB 叢集中的其他網頁伺服器一次升級一台，直到整個叢集都在 64 位元執行為止。

作業小組通常會同時將指定 NLB 叢集中的所有伺服器升級。全球的負載平衡服務可讓整個 NLB 叢集在伺服器升級活動期間暫時從服務移除。作業小組會對其餘的 NLB 叢集重複一次升級 NLB 叢集中的所有伺服器之程序，直到資料中心中的所有網頁伺服器都執行 64 位元版本的 Windows 為止。接著在下一個資料中心重複該程序，直到 www.microsoft.com 的所有網頁伺服器都執行 64 位元版本的 Windows 為止。

可以將 NLB 叢集一次遷移一個至新 x64 為主的標準組建，因為實際執行伺服器已經在 x64 為主的硬體上執行。這個遷移方法可順利分階段的遷移，而不會影響生產力或效能。這個分階段的方法也允許精細等級的復原策略。如果個別的伺服器遇到問題，作業小組可以快速從叢集移除伺服器，然後將伺服器重建為 32 位元或 64 位元伺服器。

轉換經驗

在本專案開始之前，Microsoft.com 作業小組其中一個最關心的議題就是修改應用程式與元件，以便能在 x64 為主的作業系統上正常運作所需的工作量。作業小組很快地瞭解到如果設定正確，WoW64 模擬環境將可幾乎消除做任何修改的需要。具體而言，作業小組並不需要修改任何一行的程式碼或是重新編譯下列任何元件或應用程式：

• 32 位元網際網路伺服器應用程式發展介面 (ISAPI) 篩選器

• 較舊的 Component Object Model (COM) 元件

• Microsoft ASP.NET 版本 1.1 應用程式

作業小組也確定了在兩個平台之間執行 32 位元應用程式的差別微乎其微，因為在 x64 為主的 CPU 中有 32 位元的暫存器。

32 位元與 64 位元應用程式的並存裝載

雖然作業小組可以將硬體與作業系統平台完全遷移到 64 位元，不過在 32 位元應用程式元件上仍有許多相依性，需要 IIS 在 WoW64 之下執行 32 位元工作者處理序。許多應用程式是以 ASP.NET 1.1 所撰寫，它是使用 Microsoft .NET Framework version 1.1，而且該版本不是 64 位元相容。同樣地，ISAPI 延伸模組與篩選器以及已經編譯數年之久的自訂和較舊的 COM 元件，都需要 32 位元處理序。

因此，作業小組需要設定 IIS 才能在 32 位元 WoW64 環境中為應用程式集區執行工作者處理序。如需如何設定 IIS Metabase 機碼，以指示 IIS 使用 32 位元的工作者處理序，而不是原生 64 位元工作者處理序的說明，請參閱知識庫文章＜Windows Server 2003 SP1 允許 IIS 6.0 中 32 位元 Web 應用程式的 WOW64 相容性＞，網址為 https://support.microsoft.com/?id=895976。依據預設，IIS 設定成在 32 位元模式操作時，為應用程式集區利用完整的 4 GB 位址空間。

當將 IIS 設定成在 32 位元模式執行時，所有的處理序都會在該模式下執行。Microsoft 並不支援或是提供在相同實體伺服器的 IIS 應用程式集區中執行 32 位元與 64 位元應用程式的方法。現在可以使用 Microsoft ASP.NET version 2.0 來開發應用程式，它是使用 64 位元相容的 Microsoft NET Framework version 2.0。若要服務這些原生 64 位元 Web 應用程式，將需要一個不同的網頁伺服器組態，用以在原生 64 位元執行 IIS 來裝載這些應用程式。

注意：* *IIS version 7.0 將提共一個支援的方法，以便在相同的伺服器上同時執行 32 位元與 64 位元工作者處理序。

優點

Microsoft.com 作業小組發現遷移到 x64 平台有許多優點。最立即的優點是在個別的網頁伺服器與整個網站效能方面有重大的改善。

效能增加

Microsoft.com 作業小組發現將 Microsoft.com 網頁伺服器遷移到 x64 為主的平台，有兩個主要效能增加。第一個增加是 CPU 使用率大幅下滑，這是因為應用程式集區回收較不頻繁或是已不需要。作業小組也發現應用程式集區完全不再回收，或是以數週的頻率而不是幾分鐘的頻率來回收。這個效能議題非常重要。下列「效能監控」圖表顯示 CPU 使用率大約減少 50%。

圖 1. 64 位元伺服器處理器使用率

圖 2. 32 位元伺服器處理器使用率

除了 CPU 使用率減少 50% 之外，32 位元伺服器也經歷顯著的尖峰波形，在此 CPU 的使用率為 100% 並持續好幾段時間。作業小組判斷出當一或多個應用程式集區用完虛擬記憶體並回收時，就會發生尖峰波形。在 x64 為主的伺服器上，這些尖峰波形並不存在，因為應用程式集區不會再用完記憶體。

第二個主要的效能增加而且可以說是最重要的，是大幅改善應用程式的回應時間。這個增加直接導致使用者經驗的改善。因為伺服器再也不需要佇列或維護要回收的開啟連線，或是佇列或維護因 2 GB 或將近 2 GB 的虛擬記憶體限制而執行效能差的應用程式，伺服器可以對要求回應更快速並且更一致，如下列表格顯示。

表格 5。x86 和 x64 回應時間

需求類型	32 位元 需求/秒	32 位元回應時間 (毫秒)	64 位元 需求/秒	64 位元回應時間 (毫秒)
ASP	7.85	244	7.41	53
ISAPI	110.85	248	125.43	18
Static	41.9	135	31.01	3
Static (cached)	47.11	1	54.51	1

作業小組發現過去執行效能最差的應用程式增加了最大的回應時間。這些應用程式的效能增加相當的可觀，如下列表格顯示。

表格 6. 效能最差的應用程式

應用程式	32 位元 (秒)	64 位元 (秒)	效能增益
應用程式 1	79.3	5.1	15.5X
應用程式 2	53.5	4.7	11.3X
應用程式 3	49.4	2.8	17.7X
應用程式 4	47.7	2.7	17.4X
應用程式 5	44.8	2.6	17.4X

注意： Microsoft.com 作業小組用以產生這些數字的 Microsoft Server Performance Advisor (SPA) 在 Microsoft.com 上以免費下載的方式提供，網址為 https://www.microsoft.com/downloads/details.aspx?FamilyID=61a41d78-e4aa-47b9-901b-cf85da075a73&DisplayLang=en

硬體整併

要判斷網頁伺服器整併與遷移到 x64 為主的平台的潛力是否很大是很容易的。理論上，Microsoft.com 可減少網頁伺服器的數量達 50%。不過，作業小組決定不要減少網頁伺服器的數目，因為作業小組想要讓伺服器在更低且更一致的使用率等級來執行，而且該小組想要隨著網站的持續成長而維護額外的容量。這個額外的容量也提供完整的資料中心備援，而不會增加伺服器的數量。在移到 x64 為主的平台之前，整個資料中心的中斷將會導致該中斷持續時間的效能降低。在 x64 為主的平台上，網站的效能將在單一資料中心中斷的事件中仍然相當穩定。

Web 應用程式的行為

透過 2 GB 的位址空間，要區別流失記憶體的應用程式以及只是使用大量記憶體做為一般行為的一部分 (例如快取) 是非常困難的。透過將可用的虛擬記憶體增加到 4 GB，應用程式之後者類別的記憶體使用率通常可達到 2 GB 到 3 GB 之間的狀態。這個其他的虛擬記憶體使得識別實際上是流失記憶體的應用程式體容易多了，因為其記憶體使用率將繼續攀升到 4 GB 的限制。IT 小組可以觀察應用程式更長的時間，以協助應用程式的最後偵錯。

x64 為主的平台也能夠建立更多應用程式集區，這使得可在各種 Web 應用程式之間進一步隔離程式碼與內容。

在未來，以 ASP.NET 2.0 撰寫的應用程式將進一步改善可靠性與效能，因為它們可以定址 8 TB 的虛擬記憶體，並且可以在原生 64 位元作業系統環境中執行。ASP.NET 與 .NET Framework 2.0 也提供增強的診斷與偵錯功能。

最佳實作

Microsoft.com x64 為主的網頁伺服器遷移工作顯示的最明顯和最佳實作，是將高容量的網頁伺服器遷移到 x64 為主的硬體與軟體平台。任何考慮這類遷移的組織都應該執行 POC，以確認效能增加並識別任何程式碼遷移的相依性。

當這樣做時，Microsoft.com 作業小組根據其經驗建議下列最佳實作。

協力廠商相依性的驗證

組織應該充份瞭解任何協力廠商應用程式與驅動程式 x64 相容版本的相依性與可用性。在任何平台遷移中，組織都必須在與 x64 為主的作業系統相容的環境中確定並確保任何協力廠商相依性。任何需要核心模式驅動程式的元件都需要 x64 為主的相容驅動程式，因為 32 位元核心模式驅動程式無法用於 x64 為主的作業系統。作業小組遭遇到的一些相依性包括下列項目：

• 防毒軟體

• 備份軟體

• 映像和部署軟體

• 使用篩選磁碟的通用系統管理工具，如 Filemon 和 Regmon

指令檔的行為

組織應該充份瞭解指令碼的相依性，才能夠知道哪個指令碼裝載可以在特定環境中使用。與 32 位元 com 物件相依的指令碼將需要 32 位元的 cscript 或是 wscript 指令碼裝載版本，這些版本位於 %systemroot%\SysWow64 資料夾。當載入指令碼裝載時，組織應該特別參考此路徑。若未參考，將會啟動指令碼裝載預設的 64 位元版本。替代方案是將預設指令碼裝載變更為 32 位元版本。

使用 32 位元指令碼裝載的指令碼也需要注意 WoW64 重新導向行為，如下列小節所討論。

WoW64 檔案系統與登錄重新導向行為

組織應該要對在登錄和檔案系統中同時會發生的 WoW64 重新導向行為很熟悉。這些重新導向行為是為了協助 32 位元處理序在 64 位元環境中工作所設計。

檔案系統工作階段

在 x64 為主的作業系統中，每當 32 位元處理序嘗試存取 %systemroot%\system32 時，WoW64 層會自動將它重新導向至 %systemroot%\syswow64，這包含所有的 32 位元 Windows 二進位碼檔案。這將可防止 32 位元的處理序嘗試載入 64 位元的二進位碼檔案。

登錄工作階段

類似於檔案系統的重新導向，存取登錄也存在著相同的行為。嘗試讀取或寫入 HKEY_LOCAL_MACHINE\Software 的 32 位元處理序會重新導向至 HKEY_LOCAL_MACHINE\Software\Wow6432Node\。這個行為允許為 32 位元與 64 位元處理序維護不同的組態。任何在此節點中設定的自訂設定或機碼可能需要同時存在於這兩個機碼，因為會將 32 位元處理序重新導向到這個新分支。

結論

Microsoft.com 是網際網路上最繁忙且高度可用的網站之一。即使 Microsoft.com 網站持續地在 32 位元平台上成長，而且它已達到空前的可用性與效能等級，但是 32 位元平台固有的記憶體限制讓作業小組面臨特別的挑戰。這些挑戰需要經常介入，這使得 Web 應用程式的疑難排解和偵錯變得很困難。

做為 Microsoft 技術早期採用者的 Microsoft.com 作業小組策略，決定透過將在 x64 為主的硬體與軟體上建立的伺服器實作成容易的伺服器，以評估增加虛擬記憶體限制的優點。該專案是以概念證明開始，並快速進展到在 Microsoft.com 實際執行伺服器上執行 Windows作業系統x64 為主的發行前版本。透過順暢地遷移 32 位元應用程式 (同時提供 x64 為主的硬體與作業系統之主要功能)，作業小組可在 Microsoft 發行 x64 版本的 Windows 時達到 100% 的遷移成功。

在完成轉換到 x64 為主的平台之後，作業小組多年來一直努力解決的記憶體限制也從此消失。記憶體爭用問題消除所產生的優勢將可讓 Microsoft.com 繼續為可用性設定產業標準，同時又可大幅增加目前使用者的效能與未來的容量。新平台也可以讓下一波以 ASP.NET2.0 撰寫的 64 位元 Web 應用程式利用 64 位元相容的 .NET Framework2.0。在原生 64 位元環境中執行這些應用程式的效能預期將比在 x64 平台上執行 32 位元應用程式的效能甚至還要更好。

此白皮書的主要目的是讓 Microsoft.com 作業小組分享所知道的重要觀念與最佳實作。不過，在高流量的網頁伺服器案例中，從此白皮書所得知的最明顯觀念是遷移到 x64 為主的平台可能因順暢的遷移路徑而產生很大的好處，同時還提供相當大的潛能以實現硬體與作業成本的立即節省。

如需詳細資訊

如需更多有關 Microsoft 產品與服務的資訊，請連絡 Microsoft 銷售資訊中心，電話：(800) 426-9400。在加拿大，請連絡 Microsoft 加拿大資訊中心電話：(800) 563-9048。若您位在美國 50 州與加拿大以外的地區，請連絡您當地的 Microsoft 分公司。如需使用全球資訊網存取資訊，請造訪：

https://www.microsoft.com

https://www.microsoft.com/technet/itshowcase/infoworker.mspx

現況

Windows Server 2003 與 IIS 6.0 讓 Microsoft.com 作業團隊得以在可用性方面達到無可比擬的成果。不過，32 位元作業系統的虛擬記憶體限制對個別伺服器可用性與效能的影響愈來愈大，也綁住團隊在網頁應用程式移難排解與偵錯兩方面的能力。

解決方案

Microsoft.com 作業團隊決定率先採用 64 位元版本的 Windows Server 2003，這是為以 x64 平台為基礎的伺服器所特別設計的。遷移至 x64 平台使虛擬記憶體配置大幅增強。x64 晶片裡的 32 位元暫存器與 Windows Server 2003 64 位元版本裡的 32 位元模擬環境，都令實際上的平台遷移過程緊密無隙。

優點

• Microsoft.com 網站改善的可用性

• Microsoft.com 網頁伺服器值得注意的效能改善

• 大幅改善的一般使用者回應時間

• 網頁應用程式的移難排解與偵錯更輕鬆

• 降低硬體成本

產品與技術

• AMD Opteron x64 伺服器

• Windows Server 2003 x64 版本

• IIS 6.0

• ASP.NET 和 .NET Framework versions 1.1 和 2.0

• WoW64 模擬環境

• NLB

下載

技術性白皮書
366 KB
Microsoft Word 檔