Microsoft.com 迁移至 Windows x64 版本技术白皮书 
本页内容
摘要2004 年 3 月，大约在 Microsoft?Windows Server?2003 x64 Edition 正式发布的一年之前，Microsoft.com 就决定在 www.microsoft.com Web 生产服务器上运行该操作系统的预发布版本，从而对实施基于 x64 硬件平台的服务器进行收益评估。到了 2005 年 4 月，Microsoft.com 中 100% 的 Web 生产服务器都运行在基于 x64 的硬件和操作系统平台之上。 对于 Microsoft.com 运营小组而言，Microsoft Windows? 32 位版本所固有的虚拟内存地址空间限制对应用程序的稳定性和故障排除工作构成了越来越大的挑战。在 Windows 64 位版本中，应用程序的虚拟内存地址空间得到了极大的扩增。这一关键功能加上以高性能轻松地执行 32 位应用程序的能力，成功解决了 Microsoft.com 网站所面临的头号问题——内存争用。与配置相同的 32 位硬件相比，基于 x64 的硬件平台能够以大致相同的性能执行 32 位代码，而 Windows x64 版本中的 32 位环境也可以在不修改任何代码的情况下，运行 32 位应用程序，从而实现了了近乎无缝的平台迁移。 到 Windows x64 版本的平台升级大大延长了 Microsoft.com Web 服务器的应用程序和 Web 服务回收间的平均时间，从而提高了站点的总体可用性。更显著的是，服务器上的 CPU 负载减轻 50%，某些应用程序的页响应时间加快了 15 倍之多。 本白皮书旨在围绕 Microsoft.com 的 x64 Web 服务器解决方案，介绍有关体系结构、设计和部署方面的考虑事项和经验，从而揭示出当前的微软产品对高度可用的高性能网站所提供的价值。本文简要论述了 Microsoft.com 在 Web 平台方面的发展、运营小组在 32 位平台上遇到的难题（在 x64 平台上得到了解决）、迁移和部署策略以及最终的基础体系结构。 本文假定读者是技术决策者，并且熟悉各种 Windows Server 2003 Web 服务器技术（比如：Internet Information Services [IIS] 6.0 版、Microsoft ASP.NET 和 Microsoft .NET Framework）以及相关的技术（网络负载平衡 [NLB] 和 Microsoft SQL Server?2000。）企业可以运用本文所介绍的许多原则和技巧，制订Web 平台升级计划。同样，企业也可以将 x64 web 服务器基础结构的设计考虑事项应用于大多数各大规模的企业级 IT 环境。然而，本白皮书建立在 Microsoft.com 运营小组作为早期采纳者所获得的经验和建议的基础之上。它的用途并不要充当程序指南。每个企业环境都有其独特之处；所以，每家企业应该灵活采用本文所介绍的计划和经验教训，以满足具体的需要。 注意： 出于安全考虑，本文中作为示例使用的林、域、内部资源、企业以及内部开发的安全文件的名称仅是出于描述的目的，并不代表微软内部使用的实际名称。 简介微软的公司网站 Microsoft.com 是世界上最庞大、访问量最大的 Internet 网站之一，并且在任何时候都可以算得上是全球第四大或第五大最繁忙的网站。整个 Microsoft.com 企业横跨三个数据中心，包含数千台服务器，使用超过 1,000 个数据库，支持数千个 Web 应用程序，而且 www.microsoft.com 平均每天的访问用户超过了 1 千 3 百万人，网页点击次数超过了 7 千万次。这些用户每秒平均建立 10,000 个连接，平均对总共 80 台 Web 服务器，维护着 300,000 个并发连接。 Microsoft.com 还通过内容递送网络合作伙伴，扩展其影响范围和可用性，并通过全局负载平衡和内容缓存提高性能。 除了支持数千台生产服务器以外，运营小组还在开发至预生产或过渡阶段，支持着数百台非生产服务器以及数十台支持其网站的基础结构服务器。 如下表所示，Microsoft.com 在整个美国 Internet 用户群中的覆盖范围超过了所有其它的公司网站，并且从 2004 年 9 月起继续以 6.9% 的速度扩增。
负责 Microsoft.com 的运营小组的使命就是在 Internet 上实现最高的可用性，同时展示微软的各种技术。该运营小组还制定了一项战略，那就是作为许多微软产品的早期采纳者，向各个产品小组提供宝贵的反馈信息，同时与微软的客户分享最佳实践。 根据 Keynote 公司的调查结果，在过去三年里，Microsoft.com 在站点可用性方面，位居 Internet 网站的头把交椅。Keynote 公司在电子商务业绩管理服务领域，占据着全球第一的宝座。凭借 Keynote Global 35 监视服务，Keynote 可从全球的 35 个地点，验证整个页面及其所有组件在规定的时间间隔内可用来测量可用性。即使在任何一个测试地点，页面上只要有一个图像不可用，那么 Keynote 公司就认为站点在该时间间隔内出现了故障。下表将 Microsoft.com 与 Keynote Global 35 服务所监视的其它顶级的行业站点进行了对比。有关 Keynote Global 35 监视服务的详细信息，请在以下地址处参阅 IT Showcase 案例研究“对 Microsoft.com 进行监视和故障排除”：http://www.microsoft.com/technet/itsolutions/msit/.
虽然 Microsoft.com 网站还在不断扩展，并在 32 位硬件和操作系统平台上实现了前所未有的可用性和性能，但是 32 为平台所固有的内存限制给运营小组带来了巨大的难题。运营小组必须经常通过干预的方式来应对这些难题，从而难以对 Web 应用程序执行故障排除和调试操作。 Microsoft.com 向 64 位 Web 服务器迁移出于虚拟内存地址空间的扩增，Microsoft.com 运营小组有兴趣对在 Windows 64 位版本上运行 www.microsoft.com Web 服务器的潜在利益进行评估。 32 位平台 (x86) 的老难题Microsoft.com 运营小组例行监视并分析一系列广泛的站点级性能度量以及支持站点的各台服务器。迄今为止，该运营小组在 x86 平台上所确认的头号服务器性能瓶颈就是 Web 服务器上的内存争用。 在 Windows 32 位版本中，总虚拟内存地址空间为 4 吉字节 (GB)。默认情况下，操作系统为内核模式进程保留了 2 GB 的空间，而仅限应用程序使用剩下的 2 GB 虚拟内存地址空间。当应用程序的虚拟内存空间过分受约束或产生过多碎片时，应用程序就会出现错误或性能下滑，甚至可能无法正常工作。在 IIS 6.0 中，当出现这种情况时，必须回收应用程序池，将应用程序还原到正常的性能水平。 对于 Microsoft .NET 应用程序，公共语言运行时 (CLR) 以较大的连续块，分配虚拟内存地址空间里的内存。CLR 通过一个称为“垃圾收集”的进程，管理其堆栈中的碎片。该进程会定期压缩内存区域，以将堆栈中的内存释放出来作为连续块。内存碎片是随着 CLR 不断分配和释放内存而产生的，这个过程导致最初较大的可用内存连续块分裂为许多较小的可用内存块。受控 CLR 堆栈外的内存都会产生这种类型的碎片。随着因泄漏而导致内存消耗持续增长，加载了大量程序集，以及过多地使用 ASP.NET 缓存，CLR 的可用虚拟内存将急剧减少。 随着内存使用量的增加，尤其快达到可用上限时，垃圾收集程序必须更努力地工作，以满足分配需求。由于垃圾收集程序以升高的线程优先级运行，而且随着同一台服务器上的多个应用程序达到了虚拟内存上限，过多的垃圾收集程序活动会显示整台服务器都未响应随着时间增加的扩展周期。 可以使用 boot.ini 文件中的 /3GB 开关，将 Windows 32 位版本配置为对应用程序分配 3 GB 的内存。然而，该操作会减少分配给内核模式进程的内存量。对于高流量 Web 服务器，该操作会导致灾难性的后果。高流量 Web 服务器会创建并维护数千个并发的 TCP 网络连接，其中每个连接都需要分配有内核内存资源。尽管运用 /3GB 开关可以为应用程序多提供 1 GB 的虚拟内存，但却将内核模式进程（比如：TCP 连接管理）的虚拟内存限制到了 1 GB。尤其，该运营小组发现使用 /3GB 开关后，网络堆栈经常失败，特别表现称为 SYN 攻击的 TCP 连接请求攻击的情况下。 在 Microsoft Windows 2000 和 IIS 5.0 版中，所有网站和应用程序都运行在一个拥有单独的 2-GB 虚拟内存地址空间的共享应用程序环境中。这意味着任何性能低下的应用程序都会反过来导致其它应用程序的性能恶化，或者令服务器上的整个 Web 服务都停止。解决这一问题的方法就是回收 IIS 或重新启动服务器，以便刷新 2-GB 的虚拟内存空间分配。该操作会带来不希望看到的后果，即在回收期间从服务中移除 Web 服务器，并清除服务器上任何应用程序之前所建立的任何缓存。 Windows Server 2003 和 IIS 6.0 使 Web 管理员除了默认的网站应用程序池以外，还可以创建自定义的应用程序池。每个应用程序池都在其自己单独的虚拟内存地址空间分配中，生成专用的工作线程。通过使用应用程序池，可以分别隔离各个应用程序或者将它们合并到逻辑分组中。譬如，某个关键的应用程序可能被放在它自己的应用程序池中，以防止其它应用程序反过来影响它的性能。相反，某个性能低下的已知应用程序可能被放在专用的应用程序池中，以防止它反过来影响到其它应用程序的性能。 当某个特定的应用程序池工作不正常或达到了强行重启的指定阈值后，只会将某个或某组应用程序置于脱机状态并重新启用。最重要的是，应用程序池回收操作由操作系统通过适当的方法来执行。譬如，在应用程序池脱机之前，各个请求进行排队，同时该应用程序池的某个新进程进行实例化，以便在联机后为所有后续的请求提供服务。 注意：管理员可将应用程序池配置为按照具体的时间间隔或内存使用量阈值来重新启动。默认的设置是让应用程序池每 12 个小时自动重新启动一次。Microsoft.com 运营小组倾向于将虚拟内存的阈值设为 2 GB 而不设定时间间隔。 对于应在给定的 Web 服务器上创建多少个应用程序池，存在着一个具体的上限。对于 Microsoft.com，32 位服务器上最佳的应用程序池数量被定为 12 个。Microsoft.com 运营小组将经历整个软件开发生命周期 (SDLC) 的应用程序视为受信任的代码。而所有其它应用程序（包括许多来自伙伴企业的应用程序）均被视为不受信任的代码。Microsoft.com 运营小组通过将应用程序池中相似的代码分在同一组里，从而将受信任和不受信任的代码区分开。某些关键的应用程序或者存在已知问题（比如：内存泄漏）的应用程序可能会得到一个专用的应用程序池。但是，当在服务器上达到了最佳的应用程序池数量后，将各个应用程序单独放在其自身的应用程序池中就成为了一种不合适的奢侈选择了，因此大多数应用程序都位于共享应用程序池中。通常，最有问题的应用程序都位于不受信任的应用程序池中，但是如果某个应用程序导致了不受信任的应用程序池中的其它应用程序崩溃的话，那么站点将禁止该应用程序，直至开发人员将其修复为止。 注意：Web 应用程序开发人员可同时结合使用新发布的调试诊断工具（Debug Diagnostic Tool，包含在 IIS 诊断工具包中）和 Application Center Test（包含在 Microsoft Visual Studio?.NET）等应用程序压力测试工具，协助他们诊断 IIS 中内存泄漏的情况。 虽然通过独立的内存保护创建独立的应用程序的能力已经为 Microsoft.com 带来了巨大的利益，但是每个应用程序池仍然受制于 2-GB 的虚拟内存上限，而且内存回收的时间间隔变得越来越短了。许多应用程序或应用程序组需要 2 GB 以上的虚拟内存，只是为了能够在某个扩展周期内，以最佳的性能运行。在 2-GB 内存的限制下，极难确定某个应用程序是真的需要 2 GB 以上的内存以正常运行，还是存在内存泄漏的情况。即使能够配置阈值来强制自动的应用程序池重启，但要是频繁发生重启的话，对服务器的性能也是极大的挫伤。随着复杂的 ASP.NET 应用程序对资源需求的增加，Microsoft.com 的某些应用程序池甚至每五分钟就进行一次回收。 注意：当重新启动时，应用程序池必须为应用程序重新构建缓存元素。这通常会对性能造成很大的影响。管理员可以将应用程序池重启操作配置为遗弃旧进程，从而可以对其进行调试，但是这种方法也会对性能产生影响，而且可能需要管理员暂时让服务器脱机工作。 由于有数百个越来越复杂的应用程序在 Microsoft.com 的 Web 服务器上运行，因此虚拟内存限制带来的难题将会不断恶化。 Windows 64 位版本的潜在利益Windows 32 位版本与 64 位版本的主要差异之一就是后者多出来的位元提供了大得多的虚拟内存地址空间。针对 x64 平台的 Windows 将 43 个位元用于虚拟内存空间寻址，从而为内核提供了 8 TB 的可寻址内存，并将另外 8 TB 留给了 64 位用户模式进程。由于操作系统不再需要同内核模式操作共享 32 位地址空间，因此 32 位应用程序的虚拟内存地址空间也从 2 GB 增加到了 4 GB，相当于可用的 32 位内存地址空间的总和。可用内存的增加真正消除了对于 64 位应用程序的内存限制，同时也为 32 位应用程序带来了巨大的潜在利益。下表汇总了 Windows 32 位版本与 64 位版本在内存限制方面的不同之处。
注意：为了让 32 位应用程序利用更大的 4-GB 地址空间，在编译应用程序时，必须向编译器提供 /LARGEADDRESSAWARE 标志。当指示 IIS 6.0 在 Microsoft Windows-32-bit-On-Windows-64-bit 或 WoW64 环境下运行工作进程时，将默认对其配置该标志。 微软于 2001 年引入了 Windows 2000 的 64 位版本。它的首个版本专门用于在 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。）这种设计使得 32 位或 64 位操作系统都可以部署在 x64 服务器上。此外，对于 Windows Server 2003 的 x64 版本，32 位应用程序都运行 WoW64 环境中，从而使这些应用程序可以使用 32 位寄存器来运行，同时对性能造成的影响可以忽略不计。实际上，在 WoW64 中运行的 32 位应用程序和在 x64 硬件上运行 Windows 32 位版本，在性能上常常优于同等配置的 32 位服务器。在 x64 硬件上运行 32 位应用程序时，Microsoft.com 运营小组并没有发现任何负面的性能影响。 运行 64 位操作系统并克服 32 位操作系统的虚拟内存限制，同时在无需修改代码的情况下为 32 位应用程序提供相当或更好的性能，这种能力非常有发展前景。由于今后的硬件成本可能更低，因此 x64 硬件及操作系统平台可能会带来更高的性价比。 基于对潜在利益的考虑，2004 年 3 月大约在 Windows Server 2003 x64 版本正式发布的前一年，Microsoft.com 运营小组决定通过执行概念验证 (POC) 测试，再在 Microsoft.com 生产服务器上运行该操作系统的预发布版本，对实施构建在 x64 硬件平台上的服务器进行收益评估。 采纳策略与方法对新平台执行全面测试之前，运营小组必须对 x64 服务器制定一个与 32 位服务器的当前配置相似的标准配置，这一点很重要。 Microsoft.com 如何开始向 x64 平台迁移Www.microsoft.com 网站由 80 台配置完全相同的 Web 服务器为其提供服务支持，这 80 台服务器每 8 台为一组，组成了 10 个负载平衡群集，每台服务器均运用了 NLB 技术。由于冗余水平是如此之高，因此该运营小组可以在不影响整个站点的可用性或性能的情况下，对特定的 NLB 群集添加或移除服务器。通过对一个 x64 服务器配置与现有的某台服务器相同的内容、应用程序和设置，该运营小组就可以将这台新服务器添加到某个现有的生产群集中，并监视其性能。 注意：管理员通常会创建一个 IP 负载平衡 NLB 群集，并让所有群集成员主动为一组配置相同的服务器的请求，提供相对静态的内容和数据。不同于使用 Microsoft 群集服务的故障转移群集，NLB 群集对服务器间的共享存储没有任何要求或需求。 Microsoft.com 运营小组通过一个标准的操作系统映像，构建了所有 Microsoft.com 服务器，然后通过应用配置脚本（可确保该小组以相同的方法构建并配置所有服务器），将服务器配置为 Web 服务器。有关 Microsoft.com 服务器配置的详细信息，请在以下地址处，参阅 IT Showcase note on IT“Microsoft.com 标准服务器配置”：http://www.microsoft.com/technet/itsolutions/msit/。 为了评估 x64 服务器，该运营小组创建一个标准的 Web 服务器内部版本，包括基础操作系统和一个脚本型 Web 服务器配置。该 x64 操作系统的 Build 1171 版本是运营小组选择用于部署的首个版本。随后，运营小组使用 AMD 公司提供的硬件和新创建的标准服务器内部版本，执行了概念验证测试。运营小组按照下表的说明配置了概念验证服务器。
基础操作系统配置包括部署到数据中心所需的所有系统工具和应用程序。Windows 的 x64 版本需要特定的硬件设备驱动程序以及包含内核模式访问的工具或应用程序（比如：防病毒程序）。运营小组必须获取并测试适当的驱动程序，以进行功能确认。在基础操作系统映像经过配置并趋于稳定之后，运营小组逐渐在测试实验室中，针对新平台测试各种应用程序。这方面的测试需要投入大量的时间和精力，因为每台配置相同的 Microsoft.com Web 服务器都承载着 350 个虚拟根、190 个 IIS Web 应用程序和 12 个应用程序池。 在进行概念验证的同时，Microsoft.com 运营小组还采购了基于 x64 的硬件，以置换 32 位服务器。正如上一节所提到的，x64 平台既可运行 Windows 的 32 位版本，又能运行 64 位版本。最初，运营小组结合标准的 32 位操作系统 Web 服务器配置，构建了新式的 x64 服务器，并将它们部署到生产环境中。这里，运营小组还将一个 NLB 群集里的服务器数量从 6 台增加到了 8 台，从而更改了 NLB 群集的体系结构。 在完成概念验证的实验室测试后，运营小组将概念验证服务器添加到了一个 NLB 生产群集中。运营小组观察了该服务器处理活动流量的情况，最终确认可以向 x64 平台执行全面迁移。随后，运营小组逐一升级其它的 Web 服务器，直至整个群集都运行在 64 位平台上。 运营小组通常在给定的 NLB 群集中，同时对所有服务器进行升级。有种全局负载平衡服务可使整个 NLB 群集在服务器升级时，临时停止提供服务。运营小组对剩下的 NLB 群集，采用这种一次性升级 NLB 群集中所有服务器的方法，直至数据中心里的所有 Web 服务器都开始运行 Windows 64 位版本。然后又对下一个数据中心采取同样的步骤，直至 www.microsoft.com 的所有 Web 服务器都运行 Windows 64 位版本。 可以将 NLB 群集逐一迁移到新的 x64 标准内部版本，因为生产服务器已经运行在 x64 硬件之上。这种迁移方法实现了顺畅的分阶段迁移，同时又不影响到生产能力或性能。这种分阶段方法还支持精确的回滚策略。如果某台服务器遇到了问题，运营小组可以迅速从群集中移除该服务器，然后将其重新构建为 32 位或 64 位服务器。 过渡体验在项目开始之前，Microsoft.com 运营小组最关心的一件事情就是修改应用程序和组件使之在 x64 操作系统上正常工作所需的工作量。该运营小组很快意识到只要配置正确，WoW64 仿真环境实际上根本不需要任何修改。尤其，运营小组不必更动任何一行代码，也不用重新编译以下任何一个组件或应用程序：
运营小组还确认由 x64 CPU 中 32 位寄存器的作用，32 位应用程序在两种平台上的性能表现几乎没有差异。 并行承载 32 位和 64 位应用程序尽管运营小组可以将硬件和操作系统平台彻底迁移到 64 位，但是仍然与 32 位应用程序组件存在着许多相关性，从而需要 IIS 在 WoW64 下运行 32 位工作进程。许多应用程序都是在 ASP.NET 1.1 中编写的，而 ASP.NET 1.1 所使用的 Microsoft .NET Framework 1.1 版并不支持 64 位。同样，ISAPI 扩展和筛选器以及多年来所编译的自定义及旧的 COM 组件，也都需要 32 位进程。 因此，运营小组需要将 IIS 配置为在 32 位 WoW64 环境中，运行应用程序池的工作进程。有关如何配置 IIS 元数据库注册表项，以指示 IIS 使用 32 位工作进程而非纯 64 位工作进程的说明，请在以下地址处，参阅知识库文章“Windows Server 2003 SP1 对 IIS 6.0 中的 32 位 Web 应用程序实现了 WOW64 兼容性”：http://support.microsoft.com/?id=895976。在 32 位模式下运行时，IIS 被默认配置为对应用程序池，运用全部 4-GB 的地址空间。 当 IIS 被配置为在 32 位模式下运行时，所有进程都将运行在此模式下。微软不支持在同一台物理服务器的 IIS 应用程序池中，同时运行 32 位和 64 位应用程序，并且也不提供相应的解决方法。如今，用户已可以在 Microsoft ASP.NET 2.0 版中开发应用程序。Microsoft ASP.NET 2.0 版使用了支持 64 位的 Microsoft NET Framework 2.0 版。为了处理这些纯 64 位 Web 应用程序，就需要单独的 Web 服务器配置，用以在纯 64 位中运行 IIS，从而承载这些应用程序。 注意： IIS 7.0 版将提供一种受支持的方法，用以在同一台服务器上同时运行 32 位和 64 位工作进程。 收益迁移到 x64 平台之后，Microsoft.com 运营小组受益匪浅。立竿见影的收益就是各台 Web 服务器及整个网站的性能都得到了大幅提升。 性能提升通过将 Microsoft.com Web 服务器迁移到 x64 平台，Microsoft.com 运营小组实现了两大性能提升。首先就是 CPU 使用率大大降低，因为应用程序池回收的频率降低，甚至不再执行了。该运营小组还发现应用程序池完全不再进行回收了，或者每周（而不是几分钟）才回收一次。由此带来的性能提升极其显著。下列性能监视器所给出的示意图显示了 CPU 使用率降低了近 50%。  图 1. 64 位服务器的处理器使用率 图 2. 32 位服务器的处理器使用率 除了 CPU 使用率降低了 50% 以外，32 位服务器还达到了许多次明显的峰值，即 CPU 使用率在持续的时间段内维持在 100%。运营小组确定当一个或多个应用程序池因耗尽虚拟内存而进行回收时，就会出现峰值情形。在 x64 服务器上，并没有出现这么多峰值，因为应用程序池不会再耗尽内存了。 另外一大性能提升（也可以说是最重要的）表现在大幅缩短的应用程序响应时间。这一性能提升直接带来了改善的最终用户体验。因为不必再为了进行回收而对开放连接或者达到或接近 2-GB 虚拟内存上限的性能低下的应用程序进行排队或维护，所以服务器可以更快、更一致地响应请求，如下表所示。
运营小组发现过去性能一直最差的应用程序实现了最大的响应时间提升。这些应用程序的性能得到了极大的提升，如下表所示。
注意： Microsoft.com 运营小组使用 Microsoft Server Performance Advisor (SPA) 生成了上述数据，用户可以在 Microsoft.com 上，免费下载该工具： http://www.microsoft.com/downloads/details.aspx?FamilyID=61a41d78-e4aa-47b9-901b-cf85da075a73&DisplayLang=en 硬件考虑事项人们很容易就可以得出这样的结论：Web 服务器合并加上向 x64 平台迁移可带来巨大的潜力。理论上，Microsoft.com 可以将 Web 服务器的数量减少 50%。然而，运营小组不选择减少 Web 服务器的数量，因为他们想让服务器以更低且更一致的利用率运行，并且随着站点的扩展维护附加的容量。附加容量还在不增加服务器数量的情况下，提供了完整的数据中心冗余能力。在迁移到 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 Web 服务器迁移工作所揭示的最显著、最重要的最佳实践就是将大容量 Web 服务器迁移到基于 x64 的硬件和软件平台。考虑进行这类迁移的任何企业都应先进行概念验证，以便确认性能收益，并确定任何代码的迁移相关性。 在此基础上，Microsoft.com 运营小组根据自身的经验，向客户推荐了以下这些最佳实践。 确认第三方相关性企业应全面了解任何第三方相关性以及支持 x64 的应用程序和驱动程序版本的可用性。作为任何平台迁移工作的一部分，企业必须验证并确保环境中的任何第三方相关性都与 x64 操作系统相兼容。任何需要内核模式的组件都必须具有基于 x64 的兼容驱动程序，因为 32 位内核模式驱动程序无法用于 x64 操作系统。运营小组遇到的相关性涉及：
脚本行为企业应全面了解脚本相关性，以便知道在特定的环境下该使用哪个脚本主机。依赖 32 位 com 对象的脚本将需要位于 %systemroot%\SysWow64 文件夹的 32 位 cscript 或 wscript 脚本主机版本。企业应在启动脚本主机时，特别引用该路经。如果不这么做的话，那么将启动脚本主机的默认 64 位版本。另外一种方法是将默认的脚本主机改为 32 位版本。 使用 32 位脚本主机的脚本也需要知道 WoW64 重定向行为，具体见下一节的说明。 WoW64 文件系统和注册表重定向行为企业应熟悉注册表和文件系统中的 WoW64 重定向行为。这类重定向行为专门用以协助 64 位环境中的 32 位工作进程。 文件系统重定向 在 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 是 Internet 上最繁忙且可用性最高的网站之一。尽管 Microsoft.com 网站一直在 32 位平台上实现持续扩展，并且达到了前所未有的可用性和性能水平，但是 32 位平台固有的内存限制给运营小组带来了特殊的难题。运营小组必须经常通过干预的方式来应对这些难题，从而难以对 Web 应用程序进行故障排除和调试。 作为微软技术早期采纳者的策略很容易就促使 Microsoft.com 运营小组决定通过实施围绕 x64 硬件和软件而构建的服务器，对虚拟内存上限的提高进行收益评估。该项目开始之初进行了概念验证，随后迅速进入了下一个阶段，即在 Microsoft.com 生产服务器上运行 Windows x64 操作系统的预发布版本。通过无缝迁移 32 位应用程序（基于 x64 的硬件和操作系统所提供的主要功能），该运营小组可以在微软发布 Windows x64 版本之时，实现百分之百的成功迁移。 完成向 x64 平台的过渡之后，运营小组多年来所头疼的内存限制随之烟消云散了。内存争用问题得以解决所带来的好处使得 Microsoft.com 能够继续对可用性设立工业标准，同时大幅提高当前的最终用户性能和未来的容量。新平台还将推动下一轮通过 ASP.NET 2.0 编写 64 位 Web 应用程序（借助支持 64 位的 .NET Framework 2.0）的浪潮。这些应用程序在纯 64 位环境中的运行性能甚至有望超越运行在 x64 平台上的 32 位应用程序。 本白皮书的主要目的之一就是要让 Microsoft.com 运营小组与客户分享他们的经验教训以及最佳实践。但是对于高流量 Web 服务器，本白皮书所提供的最显著的经验就是迁移到 x64 平台既无缝又能带来巨大的收益，同时还提供了巨大的潜力，能够立即实现硬件和操作成本节约。 更多信息有关微软产品或服务的更多信息，请拨打 (800) 426-9400 联系微软销售信息中心 (Microsoft Sales Information Center)。在加拿大，请拨打 (800) 563-9048 联系微软加拿大信息中心 (Microsoft Canada information Centre)。在美国 50 个州和加拿大之外的地区，请联系当地的微软分支机构。若要通过万维网访问信息，请登陆： http://www.microsoft.com/technet/itshowcase |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
