|
 | 摘要 |
| 簡(jiǎn)介 |
| Microsoft.com 向 64 位 Web 服務(wù)器遷移 |
| 32 位平臺(tái) (x86) 的老難題 |
| Windows 64 位版本的潛在利益 |
| 采納策略與方法 |
| 收益 |
| 最佳實(shí)踐 |
| 總結(jié) |
2004 年 3 月，大約在 Microsoft?Windows Server?2003 x64 Edition 正式發(fā)布的一年之前，Microsoft.com 就決定在 www.microsoft.com Web 生產(chǎn)服務(wù)器上運(yùn)行該操作系統(tǒng)的預(yù)發(fā)布版本，從而對(duì)實(shí)施基于 x64 硬件平臺(tái)的服務(wù)器進(jìn)行收益評(píng)估。到了 2005 年 4 月，Microsoft.com 中 100% 的 Web 生產(chǎn)服務(wù)器都運(yùn)行在基于 x64 的硬件和操作系統(tǒng)平臺(tái)之上。
對(duì)于 Microsoft.com 運(yùn)營(yíng)小組而言，Microsoft Windows? 32 位版本所固有的虛擬內(nèi)存地址空間限制對(duì)應(yīng)用程序的穩(wěn)定性和故障排除工作構(gòu)成了越來越大的挑戰(zhàn)。在 Windows 64 位版本中，應(yīng)用程序的虛擬內(nèi)存地址空間得到了極大的擴(kuò)增。這一關(guān)鍵功能加上以高性能輕松地執(zhí)行 32 位應(yīng)用程序的能力，成功解決了 Microsoft.com 網(wǎng)站所面臨的頭號(hào)問題——內(nèi)存爭(zhēng)用。與配置相同的 32 位硬件相比，基于 x64 的硬件平臺(tái)能夠以大致相同的性能執(zhí)行 32 位代碼，而 Windows x64 版本中的 32 位環(huán)境也可以在不修改任何代碼的情況下，運(yùn)行 32 位應(yīng)用程序，從而實(shí)現(xiàn)了了近乎無縫的平臺(tái)遷移。
到 Windows x64 版本的平臺(tái)升級(jí)大大延長(zhǎng)了 Microsoft.com Web 服務(wù)器的應(yīng)用程序和 Web 服務(wù)回收間的平均時(shí)間，從而提高了站點(diǎn)的總體可用性。更顯著的是，服務(wù)器上的 CPU 負(fù)載減輕 50%，某些應(yīng)用程序的頁(yè)響應(yīng)時(shí)間加快了 15 倍之多。
本白皮書旨在圍繞 Microsoft.com 的 x64 Web 服務(wù)器解決方案，介紹有關(guān)體系結(jié)構(gòu)、設(shè)計(jì)和部署方面的考慮事項(xiàng)和經(jīng)驗(yàn)，從而揭示出當(dāng)前的微軟產(chǎn)品對(duì)高度可用的高性能網(wǎng)站所提供的價(jià)值。本文簡(jiǎn)要論述了 Microsoft.com 在 Web 平臺(tái)方面的發(fā)展、運(yùn)營(yíng)小組在 32 位平臺(tái)上遇到的難題（在 x64 平臺(tái)上得到了解決）、遷移和部署策略以及最終的基礎(chǔ)體系結(jié)構(gòu)。
本文假定讀者是技術(shù)決策者，并且熟悉各種 Windows Server 2003 Web 服務(wù)器技術(shù)（比如：Internet Information Services [IIS] 6.0 版、Microsoft ASP.NET 和 Microsoft .NET Framework）以及相關(guān)的技術(shù)（網(wǎng)絡(luò)負(fù)載平衡 [NLB] 和 Microsoft SQL Server?2000。）企業(yè)可以運(yùn)用本文所介紹的許多原則和技巧，制訂Web 平臺(tái)升級(jí)計(jì)劃。同樣，企業(yè)也可以將 x64 web 服務(wù)器基礎(chǔ)結(jié)構(gòu)的設(shè)計(jì)考慮事項(xiàng)應(yīng)用于大多數(shù)各大規(guī)模的企業(yè)級(jí) IT 環(huán)境。然而，本白皮書建立在 Microsoft.com 運(yùn)營(yíng)小組作為早期采納者所獲得的經(jīng)驗(yàn)和建議的基礎(chǔ)之上。它的用途并不要充當(dāng)程序指南。每個(gè)企業(yè)環(huán)境都有其獨(dú)特之處；所以，每家企業(yè)應(yīng)該靈活采用本文所介紹的計(jì)劃和經(jīng)驗(yàn)教訓(xùn)，以滿足具體的需要。
注意： 出于安全考慮，本文中作為示例使用的林、域、內(nèi)部資源、企業(yè)以及內(nèi)部開發(fā)的安全文件的名稱僅是出于描述的目的，并不代表微軟內(nèi)部使用的實(shí)際名稱。
微軟的公司網(wǎng)站 Microsoft.com 是世界上最龐大、訪問量最大的 Internet 網(wǎng)站之一，并且在任何時(shí)候都可以算得上是全球第四大或第五大最繁忙的網(wǎng)站。整個(gè) Microsoft.com 企業(yè)橫跨三個(gè)數(shù)據(jù)中心，包含數(shù)千臺(tái)服務(wù)器，使用超過 1,000 個(gè)數(shù)據(jù)庫(kù)，支持?jǐn)?shù)千個(gè) Web 應(yīng)用程序，而且 www.microsoft.com 平均每天的訪問用戶超過了 1 千 3 百萬(wàn)人，網(wǎng)頁(yè)點(diǎn)擊次數(shù)超過了 7 千萬(wàn)次。這些用戶每秒平均建立 10,000 個(gè)連接，平均對(duì)總共 80 臺(tái) Web 服務(wù)器，維護(hù)著 300,000 個(gè)并發(fā)連接。
Microsoft.com 還通過內(nèi)容遞送網(wǎng)絡(luò)合作伙伴，擴(kuò)展其影響范圍和可用性，并通過全局負(fù)載平衡和內(nèi)容緩存提高性能。
除了支持?jǐn)?shù)千臺(tái)生產(chǎn)服務(wù)器以外，運(yùn)營(yíng)小組還在開發(fā)至預(yù)生產(chǎn)或過渡階段，支持著數(shù)百臺(tái)非生產(chǎn)服務(wù)器以及數(shù)十臺(tái)支持其網(wǎng)站的基礎(chǔ)結(jié)構(gòu)服務(wù)器。
如下表所示，Microsoft.com 在整個(gè)美國(guó) Internet 用戶群中的覆蓋范圍超過了所有其它的公司網(wǎng)站，并且從 2004 年 9 月起繼續(xù)以 6.9% 的速度擴(kuò)增。
| 表 1. 公司網(wǎng)站覆蓋率排名 | |||
| 排名 | 公司 | 唯一用戶 | 覆蓋 |
| 1 | Microsoft | 5400 萬(wàn) | 36.3 |
| 29 | Apple | 1300 萬(wàn) | 8.9 |
| 31 | Netscape | 1290 萬(wàn) | 8.7 |
| 183 | Sony | 420 萬(wàn) | 2.8 |
| 334 | IBM | 260 萬(wàn) | 1.8 |
| 469 | Sun | 200 萬(wàn) | 1.4 |
負(fù)責(zé) Microsoft.com 的運(yùn)營(yíng)小組的使命就是在 Internet 上實(shí)現(xiàn)最高的可用性，同時(shí)展示微軟的各種技術(shù)。該運(yùn)營(yíng)小組還制定了一項(xiàng)戰(zhàn)略，那就是作為許多微軟產(chǎn)品的早期采納者，向各個(gè)產(chǎn)品小組提供寶貴的反饋信息，同時(shí)與微軟的客戶分享最佳實(shí)踐。
根據(jù) Keynote 公司的調(diào)查結(jié)果，在過去三年里，Microsoft.com 在站點(diǎn)可用性方面，位居 Internet 網(wǎng)站的頭把交椅。Keynote 公司在電子商務(wù)業(yè)績(jī)管理服務(wù)領(lǐng)域，占據(jù)著全球第一的寶座。憑借 Keynote Global 35 監(jiān)視服務(wù)，Keynote 可從全球的 35 個(gè)地點(diǎn)，驗(yàn)證整個(gè)頁(yè)面及其所有組件在規(guī)定的時(shí)間間隔內(nèi)可用來測(cè)量可用性。即使在任何一個(gè)測(cè)試地點(diǎn)，頁(yè)面上只要有一個(gè)圖像不可用，那么 Keynote 公司就認(rèn)為站點(diǎn)在該時(shí)間間隔內(nèi)出現(xiàn)了故障。下表將 Microsoft.com 與 Keynote Global 35 服務(wù)所監(jiān)視的其它頂級(jí)的行業(yè)站點(diǎn)進(jìn)行了對(duì)比。有關(guān) Keynote Global 35 監(jiān)視服務(wù)的詳細(xì)信息，請(qǐng)?jiān)谝韵碌刂诽巺㈤?IT Showcase 案例研究“對(duì) Microsoft.com 進(jìn)行監(jiān)視和故障排除”：http://www.microsoft.com/technet/itsolutions/msit/.
| 表 2. 網(wǎng)站可用性排名 | ||
| 排名 | 網(wǎng)站 | 可用性 |
| 1 | Microsoft.com | 99.82 |
| 2 | Windows Update | 99.81 |
| 3 | | 99.71 |
| 4 | IBM | 99.70 |
| 5 | AOL | 99.69 |
| 6 | Dell | 98.63 |
| 8 | Oracle | 84.06 |
雖然 Microsoft.com 網(wǎng)站還在不斷擴(kuò)展，并在 32 位硬件和操作系統(tǒng)平臺(tái)上實(shí)現(xiàn)了前所未有的可用性和性能，但是 32 為平臺(tái)所固有的內(nèi)存限制給運(yùn)營(yíng)小組帶來了巨大的難題。運(yùn)營(yíng)小組必須經(jīng)常通過干預(yù)的方式來應(yīng)對(duì)這些難題，從而難以對(duì) Web 應(yīng)用程序執(zhí)行故障排除和調(diào)試操作。
出于虛擬內(nèi)存地址空間的擴(kuò)增，Microsoft.com 運(yùn)營(yíng)小組有興趣對(duì)在 Windows 64 位版本上運(yùn)行 www.microsoft.com Web 服務(wù)器的潛在利益進(jìn)行評(píng)估。
Microsoft.com 運(yùn)營(yíng)小組例行監(jiān)視并分析一系列廣泛的站點(diǎn)級(jí)性能度量以及支持站點(diǎn)的各臺(tái)服務(wù)器。迄今為止，該運(yùn)營(yíng)小組在 x86 平臺(tái)上所確認(rèn)的頭號(hào)服務(wù)器性能瓶頸就是 Web 服務(wù)器上的內(nèi)存爭(zhēng)用。
在 Windows 32 位版本中，總虛擬內(nèi)存地址空間為 4 吉字節(jié) (GB)。默認(rèn)情況下，操作系統(tǒng)為內(nèi)核模式進(jìn)程保留了 2 GB 的空間，而僅限應(yīng)用程序使用剩下的 2 GB 虛擬內(nèi)存地址空間。當(dāng)應(yīng)用程序的虛擬內(nèi)存空間過分受約束或產(chǎn)生過多碎片時(shí)，應(yīng)用程序就會(huì)出現(xiàn)錯(cuò)誤或性能下滑，甚至可能無法正常工作。在 IIS 6.0 中，當(dāng)出現(xiàn)這種情況時(shí)，必須回收應(yīng)用程序池，將應(yīng)用程序還原到正常的性能水平。
對(duì)于 Microsoft .NET 應(yīng)用程序，公共語(yǔ)言運(yùn)行時(shí) (CLR) 以較大的連續(xù)塊，分配虛擬內(nèi)存地址空間里的內(nèi)存。CLR 通過一個(gè)稱為“垃圾收集”的進(jìn)程，管理其堆棧中的碎片。該進(jìn)程會(huì)定期壓縮內(nèi)存區(qū)域，以將堆棧中的內(nèi)存釋放出來作為連續(xù)塊。內(nèi)存碎片是隨著 CLR 不斷分配和釋放內(nèi)存而產(chǎn)生的，這個(gè)過程導(dǎo)致最初較大的可用內(nèi)存連續(xù)塊分裂為許多較小的可用內(nèi)存塊。受控 CLR 堆棧外的內(nèi)存都會(huì)產(chǎn)生這種類型的碎片。隨著因泄漏而導(dǎo)致內(nèi)存消耗持續(xù)增長(zhǎng)，加載了大量程序集，以及過多地使用 ASP.NET 緩存，CLR 的可用虛擬內(nèi)存將急劇減少。
隨著內(nèi)存使用量的增加，尤其快達(dá)到可用上限時(shí)，垃圾收集程序必須更努力地工作，以滿足分配需求。由于垃圾收集程序以升高的線程優(yōu)先級(jí)運(yùn)行，而且隨著同一臺(tái)服務(wù)器上的多個(gè)應(yīng)用程序達(dá)到了虛擬內(nèi)存上限，過多的垃圾收集程序活動(dòng)會(huì)顯示整臺(tái)服務(wù)器都未響應(yīng)隨著時(shí)間增加的擴(kuò)展周期。
可以使用 boot.ini 文件中的 /3GB 開關(guān)，將 Windows 32 位版本配置為對(duì)應(yīng)用程序分配 3 GB 的內(nèi)存。然而，該操作會(huì)減少分配給內(nèi)核模式進(jìn)程的內(nèi)存量。對(duì)于高流量 Web 服務(wù)器，該操作會(huì)導(dǎo)致災(zāi)難性的后果。高流量 Web 服務(wù)器會(huì)創(chuàng)建并維護(hù)數(shù)千個(gè)并發(fā)的 TCP 網(wǎng)絡(luò)連接，其中每個(gè)連接都需要分配有內(nèi)核內(nèi)存資源。盡管運(yùn)用 /3GB 開關(guān)可以為應(yīng)用程序多提供 1 GB 的虛擬內(nèi)存，但卻將內(nèi)核模式進(jìn)程（比如：TCP 連接管理）的虛擬內(nèi)存限制到了 1 GB。尤其，該運(yùn)營(yíng)小組發(fā)現(xiàn)使用 /3GB 開關(guān)后，網(wǎng)絡(luò)堆棧經(jīng)常失敗，特別表現(xiàn)稱為 SYN 攻擊的 TCP 連接請(qǐng)求攻擊的情況下。
在 Microsoft Windows 2000 和 IIS 5.0 版中，所有網(wǎng)站和應(yīng)用程序都運(yùn)行在一個(gè)擁有單獨(dú)的 2-GB 虛擬內(nèi)存地址空間的共享應(yīng)用程序環(huán)境中。這意味著任何性能低下的應(yīng)用程序都會(huì)反過來導(dǎo)致其它應(yīng)用程序的性能惡化，或者令服務(wù)器上的整個(gè) Web 服務(wù)都停止。解決這一問題的方法就是回收 IIS 或重新啟動(dòng)服務(wù)器，以便刷新 2-GB 的虛擬內(nèi)存空間分配。該操作會(huì)帶來不希望看到的后果，即在回收期間從服務(wù)中移除 Web 服務(wù)器，并清除服務(wù)器上任何應(yīng)用程序之前所建立的任何緩存。
Windows Server 2003 和 IIS 6.0 使 Web 管理員除了默認(rèn)的網(wǎng)站應(yīng)用程序池以外，還可以創(chuàng)建自定義的應(yīng)用程序池。每個(gè)應(yīng)用程序池都在其自己?jiǎn)为?dú)的虛擬內(nèi)存地址空間分配中，生成專用的工作線程。通過使用應(yīng)用程序池，可以分別隔離各個(gè)應(yīng)用程序或者將它們合并到邏輯分組中。譬如，某個(gè)關(guān)鍵的應(yīng)用程序可能被放在它自己的應(yīng)用程序池中，以防止其它應(yīng)用程序反過來影響它的性能。相反，某個(gè)性能低下的已知應(yīng)用程序可能被放在專用的應(yīng)用程序池中，以防止它反過來影響到其它應(yīng)用程序的性能。
當(dāng)某個(gè)特定的應(yīng)用程序池工作不正常或達(dá)到了強(qiáng)行重啟的指定閾值后，只會(huì)將某個(gè)或某組應(yīng)用程序置于脫機(jī)狀態(tài)并重新啟用。最重要的是，應(yīng)用程序池回收操作由操作系統(tǒng)通過適當(dāng)?shù)姆椒▉韴?zhí)行。譬如，在應(yīng)用程序池脫機(jī)之前，各個(gè)請(qǐng)求進(jìn)行排隊(duì)，同時(shí)該應(yīng)用程序池的某個(gè)新進(jìn)程進(jìn)行實(shí)例化，以便在聯(lián)機(jī)后為所有后續(xù)的請(qǐng)求提供服務(wù)。
注意：管理員可將應(yīng)用程序池配置為按照具體的時(shí)間間隔或內(nèi)存使用量閾值來重新啟動(dòng)。默認(rèn)的設(shè)置是讓應(yīng)用程序池每 12 個(gè)小時(shí)自動(dòng)重新啟動(dòng)一次。Microsoft.com 運(yùn)營(yíng)小組傾向于將虛擬內(nèi)存的閾值設(shè)為 2 GB 而不設(shè)定時(shí)間間隔。
對(duì)于應(yīng)在給定的 Web 服務(wù)器上創(chuàng)建多少個(gè)應(yīng)用程序池，存在著一個(gè)具體的上限。對(duì)于 Microsoft.com，32 位服務(wù)器上最佳的應(yīng)用程序池?cái)?shù)量被定為 12 個(gè)。Microsoft.com 運(yùn)營(yíng)小組將經(jīng)歷整個(gè)軟件開發(fā)生命周期 (SDLC) 的應(yīng)用程序視為受信任的代碼。而所有其它應(yīng)用程序（包括許多來自伙伴企業(yè)的應(yīng)用程序）均被視為不受信任的代碼。Microsoft.com 運(yùn)營(yíng)小組通過將應(yīng)用程序池中相似的代碼分在同一組里，從而將受信任和不受信任的代碼區(qū)分開。某些關(guān)鍵的應(yīng)用程序或者存在已知問題（比如：內(nèi)存泄漏）的應(yīng)用程序可能會(huì)得到一個(gè)專用的應(yīng)用程序池。但是，當(dāng)在服務(wù)器上達(dá)到了最佳的應(yīng)用程序池?cái)?shù)量后，將各個(gè)應(yīng)用程序單獨(dú)放在其自身的應(yīng)用程序池中就成為了一種不合適的奢侈選擇了，因此大多數(shù)應(yīng)用程序都位于共享應(yīng)用程序池中。通常，最有問題的應(yīng)用程序都位于不受信任的應(yīng)用程序池中，但是如果某個(gè)應(yīng)用程序?qū)е铝瞬皇苄湃蔚膽?yīng)用程序池中的其它應(yīng)用程序崩潰的話，那么站點(diǎn)將禁止該應(yīng)用程序，直至開發(fā)人員將其修復(fù)為止。
注意：Web 應(yīng)用程序開發(fā)人員可同時(shí)結(jié)合使用新發(fā)布的調(diào)試診斷工具（Debug Diagnostic Tool，包含在 IIS 診斷工具包中）和 Application Center Test（包含在 Microsoft Visual Studio?.NET）等應(yīng)用程序壓力測(cè)試工具，協(xié)助他們?cè)\斷 IIS 中內(nèi)存泄漏的情況。
雖然通過獨(dú)立的內(nèi)存保護(hù)創(chuàng)建獨(dú)立的應(yīng)用程序的能力已經(jīng)為 Microsoft.com 帶來了巨大的利益，但是每個(gè)應(yīng)用程序池仍然受制于 2-GB 的虛擬內(nèi)存上限，而且內(nèi)存回收的時(shí)間間隔變得越來越短了。許多應(yīng)用程序或應(yīng)用程序組需要 2 GB 以上的虛擬內(nèi)存，只是為了能夠在某個(gè)擴(kuò)展周期內(nèi)，以最佳的性能運(yùn)行。在 2-GB 內(nèi)存的限制下，極難確定某個(gè)應(yīng)用程序是真的需要 2 GB 以上的內(nèi)存以正常運(yùn)行，還是存在內(nèi)存泄漏的情況。即使能夠配置閾值來強(qiáng)制自動(dòng)的應(yīng)用程序池重啟，但要是頻繁發(fā)生重啟的話，對(duì)服務(wù)器的性能也是極大的挫傷。隨著復(fù)雜的 ASP.NET 應(yīng)用程序?qū)Y源需求的增加，Microsoft.com 的某些應(yīng)用程序池甚至每五分鐘就進(jìn)行一次回收。
注意：當(dāng)重新啟動(dòng)時(shí)，應(yīng)用程序池必須為應(yīng)用程序重新構(gòu)建緩存元素。這通常會(huì)對(duì)性能造成很大的影響。管理員可以將應(yīng)用程序池重啟操作配置為遺棄舊進(jìn)程，從而可以對(duì)其進(jìn)行調(diào)試，但是這種方法也會(huì)對(duì)性能產(chǎn)生影響，而且可能需要管理員暫時(shí)讓服務(wù)器脫機(jī)工作。
由于有數(shù)百個(gè)越來越復(fù)雜的應(yīng)用程序在 Microsoft.com 的 Web 服務(wù)器上運(yùn)行，因此虛擬內(nèi)存限制帶來的難題將會(huì)不斷惡化。
Windows 32 位版本與 64 位版本的主要差異之一就是后者多出來的位元提供了大得多的虛擬內(nèi)存地址空間。針對(duì) x64 平臺(tái)的 Windows 將 43 個(gè)位元用于虛擬內(nèi)存空間尋址，從而為內(nèi)核提供了 8 TB 的可尋址內(nèi)存，并將另外 8 TB 留給了 64 位用戶模式進(jìn)程。由于操作系統(tǒng)不再需要同內(nèi)核模式操作共享 32 位地址空間，因此 32 位應(yīng)用程序的虛擬內(nèi)存地址空間也從 2 GB 增加到了 4 GB，相當(dāng)于可用的 32 位內(nèi)存地址空間的總和。可用內(nèi)存的增加真正消除了對(duì)于 64 位應(yīng)用程序的內(nèi)存限制，同時(shí)也為 32 位應(yīng)用程序帶來了巨大的潛在利益。下表匯總了 Windows 32 位版本與 64 位版本在內(nèi)存限制方面的不同之處。
| 表 3. 常規(guī)內(nèi)存上限 | ||
| 情境 | 32 位 | 64 位 |
| 總的虛擬地址空間（基于單個(gè)進(jìn)程） | 4 GB | 16 TB |
| 針對(duì)每個(gè) 32 位進(jìn)程的虛擬地址空間 | 2 GB | 2 GB |
| 針對(duì)每個(gè) 32 位進(jìn)程的虛擬地址空間（結(jié)合 /3GB 開關(guān)） | 3 GB | 無 |
| 針對(duì)每個(gè) 32 位進(jìn)程的虛擬地址空間（結(jié)合 /LARGEADDRESSAWARE 開關(guān)） | 無 | 4 GB |
| 針對(duì)每個(gè) 64 位進(jìn)程的虛擬地址空間 | 無 | 8 TB |
注意：為了讓 32 位應(yīng)用程序利用更大的 4-GB 地址空間，在編譯應(yīng)用程序時(shí)，必須向編譯器提供 /LARGEADDRESSAWARE 標(biāo)志。當(dāng)指示 IIS 6.0 在 Microsoft Windows-32-bit-On-Windows-64-bit 或 WoW64 環(huán)境下運(yùn)行工作進(jìn)程時(shí)，將默認(rèn)對(duì)其配置該標(biāo)志。
微軟于 2001 年引入了 Windows 2000 的 64 位版本。它的首個(gè)版本專門用于在 Intel Itanium 硬件平臺(tái)（也稱為 Itanium）上運(yùn)行。雖然這款 64 位操作系統(tǒng)與之后針對(duì) Itanium 的 Windows Server 2003 版本大幅提升了應(yīng)用程序的虛擬內(nèi)存地址空間的上限，但是該平臺(tái)主要面向并適合于 64 位應(yīng)用程序。同許多當(dāng)今面向 Windows Server 的應(yīng)用程序一樣，Microsoft.com Web 應(yīng)用程序?qū)ｉT用于在 32 位環(huán)境下運(yùn)行。一般而言，32 位應(yīng)用程序在 Itanium 平臺(tái)上的性能表現(xiàn)不如在 32 位平臺(tái)上那么出色。另外，與 x86 平臺(tái)服務(wù)器相比，Itanium 硬件需要大筆的資金投資。
自從 Itanium 平臺(tái)問世以來，Intel 和 AMD 這兩家公司都開發(fā)出了基于 32 位寄存器和 64 位擴(kuò)展的支持 64 位的 CPU，稱為 x64 平臺(tái)。（Intel 將其芯片稱為 EM64T。）這種設(shè)計(jì)使得 32 位或 64 位操作系統(tǒng)都可以部署在 x64 服務(wù)器上。此外，對(duì)于 Windows Server 2003 的 x64 版本，32 位應(yīng)用程序都運(yùn)行 WoW64 環(huán)境中，從而使這些應(yīng)用程序可以使用 32 位寄存器來運(yùn)行，同時(shí)對(duì)性能造成的影響可以忽略不計(jì)。實(shí)際上，在 WoW64 中運(yùn)行的 32 位應(yīng)用程序和在 x64 硬件上運(yùn)行 Windows 32 位版本，在性能上常常優(yōu)于同等配置的 32 位服務(wù)器。在 x64 硬件上運(yùn)行 32 位應(yīng)用程序時(shí)，Microsoft.com 運(yùn)營(yíng)小組并沒有發(fā)現(xiàn)任何負(fù)面的性能影響。
運(yùn)行 64 位操作系統(tǒng)并克服 32 位操作系統(tǒng)的虛擬內(nèi)存限制，同時(shí)在無需修改代碼的情況下為 32 位應(yīng)用程序提供相當(dāng)或更好的性能，這種能力非常有發(fā)展前景。由于今后的硬件成本可能更低，因此 x64 硬件及操作系統(tǒng)平臺(tái)可能會(huì)帶來更高的性價(jià)比。
基于對(duì)潛在利益的考慮，2004 年 3 月大約在 Windows Server 2003 x64 版本正式發(fā)布的前一年，Microsoft.com 運(yùn)營(yíng)小組決定通過執(zhí)行概念驗(yàn)證 (POC) 測(cè)試，再在 Microsoft.com 生產(chǎn)服務(wù)器上運(yùn)行該操作系統(tǒng)的預(yù)發(fā)布版本，對(duì)實(shí)施構(gòu)建在 x64 硬件平臺(tái)上的服務(wù)器進(jìn)行收益評(píng)估。
對(duì)新平臺(tái)執(zhí)行全面測(cè)試之前，運(yùn)營(yíng)小組必須對(duì) x64 服務(wù)器制定一個(gè)與 32 位服務(wù)器的當(dāng)前配置相似的標(biāo)準(zhǔn)配置，這一點(diǎn)很重要。
Www.microsoft.com 網(wǎng)站由 80 臺(tái)配置完全相同的 Web 服務(wù)器為其提供服務(wù)支持，這 80 臺(tái)服務(wù)器每 8 臺(tái)為一組，組成了 10 個(gè)負(fù)載平衡群集，每臺(tái)服務(wù)器均運(yùn)用了 NLB 技術(shù)。由于冗余水平是如此之高，因此該運(yùn)營(yíng)小組可以在不影響整個(gè)站點(diǎn)的可用性或性能的情況下，對(duì)特定的 NLB 群集添加或移除服務(wù)器。通過對(duì)一個(gè) x64 服務(wù)器配置與現(xiàn)有的某臺(tái)服務(wù)器相同的內(nèi)容、應(yīng)用程序和設(shè)置，該運(yùn)營(yíng)小組就可以將這臺(tái)新服務(wù)器添加到某個(gè)現(xiàn)有的生產(chǎn)群集中，并監(jiān)視其性能。
注意：管理員通常會(huì)創(chuàng)建一個(gè) IP 負(fù)載平衡 NLB 群集，并讓所有群集成員主動(dòng)為一組配置相同的服務(wù)器的請(qǐng)求，提供相對(duì)靜態(tài)的內(nèi)容和數(shù)據(jù)。不同于使用 Microsoft 群集服務(wù)的故障轉(zhuǎn)移群集，NLB 群集對(duì)服務(wù)器間的共享存儲(chǔ)沒有任何要求或需求。
Microsoft.com 運(yùn)營(yíng)小組通過一個(gè)標(biāo)準(zhǔn)的操作系統(tǒng)映像，構(gòu)建了所有 Microsoft.com 服務(wù)器，然后通過應(yīng)用配置腳本（可確保該小組以相同的方法構(gòu)建并配置所有服務(wù)器），將服務(wù)器配置為 Web 服務(wù)器。有關(guān) Microsoft.com 服務(wù)器配置的詳細(xì)信息，請(qǐng)?jiān)谝韵碌刂诽帲瑓㈤?IT Showcase note on IT“Microsoft.com 標(biāo)準(zhǔn)服務(wù)器配置”：http://www.microsoft.com/technet/itsolutions/msit/。
為了評(píng)估 x64 服務(wù)器，該運(yùn)營(yíng)小組創(chuàng)建一個(gè)標(biāo)準(zhǔn)的 Web 服務(wù)器內(nèi)部版本，包括基礎(chǔ)操作系統(tǒng)和一個(gè)腳本型 Web 服務(wù)器配置。該 x64 操作系統(tǒng)的 Build 1171 版本是運(yùn)營(yíng)小組選擇用于部署的首個(gè)版本。隨后，運(yùn)營(yíng)小組使用 AMD 公司提供的硬件和新創(chuàng)建的標(biāo)準(zhǔn)服務(wù)器內(nèi)部版本，執(zhí)行了概念驗(yàn)證測(cè)試。運(yùn)營(yíng)小組按照下表的說明配置了概念驗(yàn)證服務(wù)器。
| 表 4. 基于 x64 的測(cè)試服務(wù)器配置 | |
| 組件 | 配置 |
| 處理器 | 四顆 1.6 GHz AMD64 Opteron CPU |
| RAM | 8 GB |
| 驅(qū)動(dòng)器空間 | 50 GB（操作系統(tǒng)）、136 GB（數(shù)據(jù)）、50 GB（日志） |
| 網(wǎng)絡(luò) | 千兆位光纖（前端）、100-MB 銅線（后端） |
| 操作系統(tǒng) | Windows Server 2003 x64 Edition Build 1171 |
基礎(chǔ)操作系統(tǒng)配置包括部署到數(shù)據(jù)中心所需的所有系統(tǒng)工具和應(yīng)用程序。Windows 的 x64 版本需要特定的硬件設(shè)備驅(qū)動(dòng)程序以及包含內(nèi)核模式訪問的工具或應(yīng)用程序（比如：防病毒程序）。運(yùn)營(yíng)小組必須獲取并測(cè)試適當(dāng)?shù)尿?qū)動(dòng)程序，以進(jìn)行功能確認(rèn)。在基礎(chǔ)操作系統(tǒng)映像經(jīng)過配置并趨于穩(wěn)定之后，運(yùn)營(yíng)小組逐漸在測(cè)試實(shí)驗(yàn)室中，針對(duì)新平臺(tái)測(cè)試各種應(yīng)用程序。這方面的測(cè)試需要投入大量的時(shí)間和精力，因?yàn)槊颗_(tái)配置相同的 Microsoft.com Web 服務(wù)器都承載著 350 個(gè)虛擬根、190 個(gè) IIS Web 應(yīng)用程序和 12 個(gè)應(yīng)用程序池。
在進(jìn)行概念驗(yàn)證的同時(shí)，Microsoft.com 運(yùn)營(yíng)小組還采購(gòu)了基于 x64 的硬件，以置換 32 位服務(wù)器。正如上一節(jié)所提到的，x64 平臺(tái)既可運(yùn)行 Windows 的 32 位版本，又能運(yùn)行 64 位版本。最初，運(yùn)營(yíng)小組結(jié)合標(biāo)準(zhǔn)的 32 位操作系統(tǒng) Web 服務(wù)器配置，構(gòu)建了新式的 x64 服務(wù)器，并將它們部署到生產(chǎn)環(huán)境中。這里，運(yùn)營(yíng)小組還將一個(gè) NLB 群集里的服務(wù)器數(shù)量從 6 臺(tái)增加到了 8 臺(tái)，從而更改了 NLB 群集的體系結(jié)構(gòu)。
在完成概念驗(yàn)證的實(shí)驗(yàn)室測(cè)試后，運(yùn)營(yíng)小組將概念驗(yàn)證服務(wù)器添加到了一個(gè) NLB 生產(chǎn)群集中。運(yùn)營(yíng)小組觀察了該服務(wù)器處理活動(dòng)流量的情況，最終確認(rèn)可以向 x64 平臺(tái)執(zhí)行全面遷移。隨后，運(yùn)營(yíng)小組逐一升級(jí)其它的 Web 服務(wù)器，直至整個(gè)群集都運(yùn)行在 64 位平臺(tái)上。
運(yùn)營(yíng)小組通常在給定的 NLB 群集中，同時(shí)對(duì)所有服務(wù)器進(jìn)行升級(jí)。有種全局負(fù)載平衡服務(wù)可使整個(gè) NLB 群集在服務(wù)器升級(jí)時(shí)，臨時(shí)停止提供服務(wù)。運(yùn)營(yíng)小組對(duì)剩下的 NLB 群集，采用這種一次性升級(jí) NLB 群集中所有服務(wù)器的方法，直至數(shù)據(jù)中心里的所有 Web 服務(wù)器都開始運(yùn)行 Windows 64 位版本。然后又對(duì)下一個(gè)數(shù)據(jù)中心采取同樣的步驟，直至 www.microsoft.com 的所有 Web 服務(wù)器都運(yùn)行 Windows 64 位版本。
可以將 NLB 群集逐一遷移到新的 x64 標(biāo)準(zhǔn)內(nèi)部版本，因?yàn)樯a(chǎn)服務(wù)器已經(jīng)運(yùn)行在 x64 硬件之上。這種遷移方法實(shí)現(xiàn)了順暢的分階段遷移，同時(shí)又不影響到生產(chǎn)能力或性能。這種分階段方法還支持精確的回滾策略。如果某臺(tái)服務(wù)器遇到了問題，運(yùn)營(yíng)小組可以迅速?gòu)娜杭幸瞥摲?wù)器，然后將其重新構(gòu)建為 32 位或 64 位服務(wù)器。
在項(xiàng)目開始之前，Microsoft.com 運(yùn)營(yíng)小組最關(guān)心的一件事情就是修改應(yīng)用程序和組件使之在 x64 操作系統(tǒng)上正常工作所需的工作量。該運(yùn)營(yíng)小組很快意識(shí)到只要配置正確，WoW64 仿真環(huán)境實(shí)際上根本不需要任何修改。尤其，運(yùn)營(yíng)小組不必更動(dòng)任何一行代碼，也不用重新編譯以下任何一個(gè)組件或應(yīng)用程序：
| • | 32 位 Internet 服務(wù)器應(yīng)用程序編程接口 (ISAPI) 篩選器 |
| • | 舊的組件對(duì)象模型 (COM) 組件 |
| • | Microsoft ASP.NET 1.1 版應(yīng)用程序 |
運(yùn)營(yíng)小組還確認(rèn)由 x64 CPU 中 32 位寄存器的作用，32 位應(yīng)用程序在兩種平臺(tái)上的性能表現(xiàn)幾乎沒有差異。
盡管運(yùn)營(yíng)小組可以將硬件和操作系統(tǒng)平臺(tái)徹底遷移到 64 位，但是仍然與 32 位應(yīng)用程序組件存在著許多相關(guān)性，從而需要 IIS 在 WoW64 下運(yùn)行 32 位工作進(jìn)程。許多應(yīng)用程序都是在 ASP.NET 1.1 中編寫的，而 ASP.NET 1.1 所使用的 Microsoft .NET Framework 1.1 版并不支持 64 位。同樣，ISAPI 擴(kuò)展和篩選器以及多年來所編譯的自定義及舊的 COM 組件，也都需要 32 位進(jìn)程。
因此，運(yùn)營(yíng)小組需要將 IIS 配置為在 32 位 WoW64 環(huán)境中，運(yùn)行應(yīng)用程序池的工作進(jìn)程。有關(guān)如何配置 IIS 元數(shù)據(jù)庫(kù)注冊(cè)表項(xiàng)，以指示 IIS 使用 32 位工作進(jìn)程而非純 64 位工作進(jìn)程的說明，請(qǐng)?jiān)谝韵碌刂诽?，參閱知識(shí)庫(kù)文章“Windows Server 2003 SP1 對(duì) IIS 6.0 中的 32 位 Web 應(yīng)用程序?qū)崿F(xiàn)了 WOW64 兼容性”：http://support.microsoft.com/?id=895976。在 32 位模式下運(yùn)行時(shí)，IIS 被默認(rèn)配置為對(duì)應(yīng)用程序池，運(yùn)用全部 4-GB 的地址空間。
當(dāng) IIS 被配置為在 32 位模式下運(yùn)行時(shí)，所有進(jìn)程都將運(yùn)行在此模式下。微軟不支持在同一臺(tái)物理服務(wù)器的 IIS 應(yīng)用程序池中，同時(shí)運(yùn)行 32 位和 64 位應(yīng)用程序，并且也不提供相應(yīng)的解決方法。如今，用戶已可以在 Microsoft ASP.NET 2.0 版中開發(fā)應(yīng)用程序。Microsoft ASP.NET 2.0 版使用了支持 64 位的 Microsoft NET Framework 2.0 版。為了處理這些純 64 位 Web 應(yīng)用程序，就需要單獨(dú)的 Web 服務(wù)器配置，用以在純 64 位中運(yùn)行 IIS，從而承載這些應(yīng)用程序。
注意： IIS 7.0 版將提供一種受支持的方法，用以在同一臺(tái)服務(wù)器上同時(shí)運(yùn)行 32 位和 64 位工作進(jìn)程。
遷移到 x64 平臺(tái)之后，Microsoft.com 運(yùn)營(yíng)小組受益匪淺。立竿見影的收益就是各臺(tái) Web 服務(wù)器及整個(gè)網(wǎng)站的性能都得到了大幅提升。
通過將 Microsoft.com Web 服務(wù)器遷移到 x64 平臺(tái)，Microsoft.com 運(yùn)營(yíng)小組實(shí)現(xiàn)了兩大性能提升。首先就是 CPU 使用率大大降低，因?yàn)閼?yīng)用程序池回收的頻率降低，甚至不再執(zhí)行了。該運(yùn)營(yíng)小組還發(fā)現(xiàn)應(yīng)用程序池完全不再進(jìn)行回收了，或者每周（而不是幾分鐘）才回收一次。由此帶來的性能提升極其顯著。下列性能監(jiān)視器所給出的示意圖顯示了 CPU 使用率降低了近 50%。
圖 1. 64 位服務(wù)器的處理器使用率
圖 2. 32 位服務(wù)器的處理器使用率
除了 CPU 使用率降低了 50% 以外，32 位服務(wù)器還達(dá)到了許多次明顯的峰值，即 CPU 使用率在持續(xù)的時(shí)間段內(nèi)維持在 100%。運(yùn)營(yíng)小組確定當(dāng)一個(gè)或多個(gè)應(yīng)用程序池因耗盡虛擬內(nèi)存而進(jìn)行回收時(shí)，就會(huì)出現(xiàn)峰值情形。在 x64 服務(wù)器上，并沒有出現(xiàn)這么多峰值，因?yàn)閼?yīng)用程序池不會(huì)再耗盡內(nèi)存了。
另外一大性能提升（也可以說是最重要的）表現(xiàn)在大幅縮短的應(yīng)用程序響應(yīng)時(shí)間。這一性能提升直接帶來了改善的最終用戶體驗(yàn)。因?yàn)椴槐卦贋榱诉M(jìn)行回收而對(duì)開放連接或者達(dá)到或接近 2-GB 虛擬內(nèi)存上限的性能低下的應(yīng)用程序進(jìn)行排隊(duì)或維護(hù)，所以服務(wù)器可以更快、更一致地響應(yīng)請(qǐng)求，如下表所示。
| 表 5. x86 與 x64 的響應(yīng)時(shí)間對(duì)比 | ||||
| 請(qǐng)求類型 | 32 位 | 32 位響應(yīng)時(shí)間 | 64 位 | 64 位響應(yīng)時(shí)間 |
| ASP | 7.85 | 244 | 7.41 | 53 |
| ISAPI | 110.85 | 248 | 125.43 | 18 |
| 靜態(tài) | 41.9 | 135 | 31.01 | 3 |
| 靜態(tài) | 47.11 | 1 | 54.51 | 1 |
運(yùn)營(yíng)小組發(fā)現(xiàn)過去性能一直最差的應(yīng)用程序?qū)崿F(xiàn)了最大的響應(yīng)時(shí)間提升。這些應(yīng)用程序的性能得到了極大的提升，如下表所示。
| 表 6. 性能最差的應(yīng)用程序 | |||
| 應(yīng)用程序 | 32 位（秒） | 64 位（秒） | 性能提升 |
| 應(yīng)用程序 1 | 79.3 | 5.1 | 15.5 倍 |
| 應(yīng)用程序 2 | 53.5 | 4.7 | 11.3 倍 |
| 應(yīng)用程序 3 | 49.4 | 2.8 | 17.7 倍 |
| 應(yīng)用程序 4 | 47.7 | 2.7 | 17.4 倍 |
| 應(yīng)用程序 5 | 44.8 | 2.6 | 17.4 倍 |
注意： Microsoft.com 運(yùn)營(yíng)小組使用 Microsoft Server Performance Advisor (SPA) 生成了上述數(shù)據(jù)，用戶可以在 Microsoft.com 上，免費(fèi)下載該工具： http://www.microsoft.com/downloads/details.aspx?FamilyID=61a41d78-e4aa-47b9-901b-cf85da075a73&DisplayLang=en
人們很容易就可以得出這樣的結(jié)論：Web 服務(wù)器合并加上向 x64 平臺(tái)遷移可帶來巨大的潛力。理論上，Microsoft.com 可以將 Web 服務(wù)器的數(shù)量減少 50%。然而，運(yùn)營(yíng)小組不選擇減少 Web 服務(wù)器的數(shù)量，因?yàn)樗麄兿胱尫?wù)器以更低且更一致的利用率運(yùn)行，并且隨著站點(diǎn)的擴(kuò)展維護(hù)附加的容量。附加容量還在不增加服務(wù)器數(shù)量的情況下，提供了完整的數(shù)據(jù)中心冗余能力。在遷移到 x64 平臺(tái)之前，當(dāng)整個(gè)數(shù)據(jù)中心耗盡資源時(shí)，就會(huì)導(dǎo)致性能在此期間下滑。而在 x64 平臺(tái)上，當(dāng)某個(gè)數(shù)據(jù)中心耗盡資源時(shí)，站點(diǎn)的性能仍將保持相對(duì)穩(wěn)定。
當(dāng)?shù)刂房臻g為 2-GB 時(shí)，極難將泄漏內(nèi)存的應(yīng)用程序與將大量?jī)?nèi)存用于常規(guī)操作（比如：緩存）的應(yīng)用程序區(qū)分開。而當(dāng)可用的虛擬內(nèi)存增加到 4 GB 時(shí)，后面這一類應(yīng)用程序的內(nèi)存使用量通常會(huì)達(dá)到 2 GB 至 3 GB 的水平。額外多出的這部分虛擬內(nèi)存使得很容易就能識(shí)別出正在泄漏內(nèi)存的應(yīng)用程序，因?yàn)槠鋬?nèi)存使用量將一直攀升至 4-GB 的上限。IT 小組可以在更長(zhǎng)的時(shí)間段內(nèi)觀測(cè)該應(yīng)用程序，從而有助于最終的調(diào)試。
基于 x64 的平臺(tái)還提供了創(chuàng)建更多應(yīng)用程序池的能力，從而進(jìn)一步將各個(gè) Web 應(yīng)用程序間的代碼與內(nèi)容相分離。
以后，在 ASP.NET 2.0 中編寫的應(yīng)用程序?qū)⑦M(jìn)一步提高可用性和性能，因?yàn)檫@些應(yīng)用程序可以處理 8 TB 的虛擬內(nèi)存，并可在純 64 位操作系統(tǒng)環(huán)境下執(zhí)行。ASP.NET 和 .NET Framework 2.0 還提供了增強(qiáng)的診斷和調(diào)試功能。
Microsoft.com x64 Web 服務(wù)器遷移工作所揭示的最顯著、最重要的最佳實(shí)踐就是將大容量 Web 服務(wù)器遷移到基于 x64 的硬件和軟件平臺(tái)。考慮進(jìn)行這類遷移的任何企業(yè)都應(yīng)先進(jìn)行概念驗(yàn)證，以便確認(rèn)性能收益，并確定任何代碼的遷移相關(guān)性。
在此基礎(chǔ)上，Microsoft.com 運(yùn)營(yíng)小組根據(jù)自身的經(jīng)驗(yàn)，向客戶推薦了以下這些最佳實(shí)踐。
企業(yè)應(yīng)全面了解任何第三方相關(guān)性以及支持 x64 的應(yīng)用程序和驅(qū)動(dòng)程序版本的可用性。作為任何平臺(tái)遷移工作的一部分，企業(yè)必須驗(yàn)證并確保環(huán)境中的任何第三方相關(guān)性都與 x64 操作系統(tǒng)相兼容。任何需要內(nèi)核模式的組件都必須具有基于 x64 的兼容驅(qū)動(dòng)程序，因?yàn)?32 位內(nèi)核模式驅(qū)動(dòng)程序無法用于 x64 操作系統(tǒng)。運(yùn)營(yíng)小組遇到的相關(guān)性涉及：
| • | 防病毒軟件 |
| • | 備份軟件 |
| • | 映像制作和部署軟件 |
| • | 使用 Filemon、Regmon 等篩選器驅(qū)動(dòng)程序的常規(guī)管理工具 |
企業(yè)應(yīng)全面了解腳本相關(guān)性，以便知道在特定的環(huán)境下該使用哪個(gè)腳本主機(jī)。依賴 32 位 com 對(duì)象的腳本將需要位于 %systemroot%\SysWow64 文件夾的 32 位 cscript 或 wscript 腳本主機(jī)版本。企業(yè)應(yīng)在啟動(dòng)腳本主機(jī)時(shí)，特別引用該路經(jīng)。如果不這么做的話，那么將啟動(dòng)腳本主機(jī)的默認(rèn) 64 位版本。另外一種方法是將默認(rèn)的腳本主機(jī)改為 32 位版本。
使用 32 位腳本主機(jī)的腳本也需要知道 WoW64 重定向行為，具體見下一節(jié)的說明。
企業(yè)應(yīng)熟悉注冊(cè)表和文件系統(tǒng)中的 WoW64 重定向行為。這類重定向行為專門用以協(xié)助 64 位環(huán)境中的 32 位工作進(jìn)程。
文件系統(tǒng)重定向
在 x64 操作系統(tǒng)中，只要 32 位進(jìn)程嘗試訪問 %systemroot%\system32，WoW64 層就將自動(dòng)將其重定向到 %systemroot%\syswow64（包含所有 32 位 Windows 二進(jìn)制）。這樣可以防止 32 位進(jìn)程嘗試加載 64 位二進(jìn)制。
注冊(cè)表重定向
與文件系統(tǒng)重定向相似，注冊(cè)表訪問也存在同樣的行為。任何嘗試讀取或?qū)懭?HKEY_LOCAL_MACHINE\Software 的 32 位進(jìn)程都會(huì)被重定向到 HKEY_LOCAL_MACHINE\Software\Wow6432Node\。該行為可實(shí)現(xiàn)對(duì) 32 位和 64 位進(jìn)程維護(hù)各不相同的配置。在此節(jié)點(diǎn)中設(shè)置的任何自定義設(shè)置或注冊(cè)表項(xiàng)都必須存在于這兩個(gè)注冊(cè)表項(xiàng)中，因?yàn)?32 位進(jìn)程將被重定向到這個(gè)新分支上。
Microsoft.com 是 Internet 上最繁忙且可用性最高的網(wǎng)站之一。盡管 Microsoft.com 網(wǎng)站一直在 32 位平臺(tái)上實(shí)現(xiàn)持續(xù)擴(kuò)展，并且達(dá)到了前所未有的可用性和性能水平，但是 32 位平臺(tái)固有的內(nèi)存限制給運(yùn)營(yíng)小組帶來了特殊的難題。運(yùn)營(yíng)小組必須經(jīng)常通過干預(yù)的方式來應(yīng)對(duì)這些難題，從而難以對(duì) Web 應(yīng)用程序進(jìn)行故障排除和調(diào)試。
作為微軟技術(shù)早期采納者的策略很容易就促使 Microsoft.com 運(yùn)營(yíng)小組決定通過實(shí)施圍繞 x64 硬件和軟件而構(gòu)建的服務(wù)器，對(duì)虛擬內(nèi)存上限的提高進(jìn)行收益評(píng)估。該項(xiàng)目開始之初進(jìn)行了概念驗(yàn)證，隨后迅速進(jìn)入了下一個(gè)階段，即在 Microsoft.com 生產(chǎn)服務(wù)器上運(yùn)行 Windows x64 操作系統(tǒng)的預(yù)發(fā)布版本。通過無縫遷移 32 位應(yīng)用程序（基于 x64 的硬件和操作系統(tǒng)所提供的主要功能），該運(yùn)營(yíng)小組可以在微軟發(fā)布 Windows x64 版本之時(shí)，實(shí)現(xiàn)百分之百的成功遷移。
完成向 x64 平臺(tái)的過渡之后，運(yùn)營(yíng)小組多年來所頭疼的內(nèi)存限制隨之煙消云散了。內(nèi)存爭(zhēng)用問題得以解決所帶來的好處使得 Microsoft.com 能夠繼續(xù)對(duì)可用性設(shè)立工業(yè)標(biāo)準(zhǔn)，同時(shí)大幅提高當(dāng)前的最終用戶性能和未來的容量。新平臺(tái)還將推動(dòng)下一輪通過 ASP.NET 2.0 編寫 64 位 Web 應(yīng)用程序（借助支持 64 位的 .NET Framework 2.0）的浪潮。這些應(yīng)用程序在純 64 位環(huán)境中的運(yùn)行性能甚至有望超越運(yùn)行在 x64 平臺(tái)上的 32 位應(yīng)用程序。
本白皮書的主要目的之一就是要讓 Microsoft.com 運(yùn)營(yíng)小組與客戶分享他們的經(jīng)驗(yàn)教訓(xùn)以及最佳實(shí)踐。但是對(duì)于高流量 Web 服務(wù)器，本白皮書所提供的最顯著的經(jīng)驗(yàn)就是遷移到 x64 平臺(tái)既無縫又能帶來巨大的收益，同時(shí)還提供了巨大的潛力，能夠立即實(shí)現(xiàn)硬件和操作成本節(jié)約。
有關(guān)微軟產(chǎn)品或服務(wù)的更多信息，請(qǐng)撥打 (800) 426-9400 聯(lián)系微軟銷售信息中心 (Microsoft Sales Information Center)。在加拿大，請(qǐng)撥打 (800) 563-9048 聯(lián)系微軟加拿大信息中心 (Microsoft Canada information Centre)。在美國(guó) 50 個(gè)州和加拿大之外的地區(qū)，請(qǐng)聯(lián)系當(dāng)?shù)氐奈④浄种C(jī)構(gòu)。若要通過萬(wàn)維網(wǎng)訪問信息，請(qǐng)登陸：
http://www.microsoft.com/technet/itshowcase
聯(lián)系客服
