Technical White Paper

Published: February 9, 2006

Executive Summary

In March 2004, approximately one year in advance of the official release of Microsoft® Windows Server™ 2003 x64 Edition, Microsoft.com decided to evaluate the benefits of implementing servers built on the x64-based hardware platform by running prerelease versions of that operating system on production www.microsoft.com Web servers. By April 2005, 100 percent of the production Web servers for Microsoft.com were running on the x64-based hardware and operating system platforms.

The virtual memory address space limitation that is inherent with the 32-bit versions of Microsoft Windows® had increasingly led to challenges in application stability and troubleshooting for the Microsoft.com operations team. With 64-bit versions of Windows, the virtual memory address space for an application is greatly increased. That crucial feature combined with the ability to easily execute 32-bit applications with high performance has resolved what had become the number one issue for the Microsoft.com site—memory contention. The x64-based hardware platform can natively execute 32-bit code at roughly the same performance levels as similarly configured 32-bit hardware, and yet the 32-bit environment within the x64 version of Windows also enables 32-bit applications to run without any code modification, making the platform migration virtually seamless.

The resulting platform upgrade to the x64 version of Windows has drastically increased the mean time between application and Web service recycling for Microsoft.com Web servers, thereby increasing the overall site availability. More impressively, the CPU load on the servers decreased by 50 percent, and page response times for some applications are up to fifteen times faster.

The purpose of this white paper is to share architecture, design, and deployment considerations and experiences based on the Microsoft.com x64-based Web server solution to demonstrate the value of current Microsoft products concerning highly available, high-performance Web sites. This paper briefly discusses the evolution of the Web platform at Microsoft.com, the challenges that the operations team encountered with the 32-bit platform that the x64-based platform resolved, the migration and deployment strategy, and the resulting infrastructure architecture.

This paper assumes that readers are technical decision makers and are already familiar with Windows Server 2003 Web server technologies, such as Internet Information Services (IIS) version 6.0, Microsoft ASP.NET, and the Microsoft .NET Framework, and with associated technologies, such as Network Load Balancing (NLB) and Microsoft SQL Server™ 2000. An organization can employ many of the principles and techniques that this paper describes to plan a Web platform upgrade. Likewise, an organization can apply the design considerations for an x64-based Web server infrastructure to most any enterprise-scale IT environment. However, this paper is based on the Microsoft.com operations team's experience and recommendations as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned that this paper describes to meet its specific needs.

Note: For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names that are used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.

Introduction

The Microsoft corporate Web site, Microsoft.com, is one of the largest and most heavily visited sites on the Internet, ranking as the fourth or fifth busiest site on any given day. The entire Microsoft.com enterprise spans three data centers and consists of thousands of servers, uses more than 1,000 databases, supports thousands of Web applications, and www.microsoft.com specifically averages more than 13 million unique users and 70 million page views per day. These users average 10,000 connections per second and maintain an average of 300,000 concurrent connections to a total of 80 Web servers.

Microsoft.com also uses content delivery network partners to extend its reach and availability, and to improve performance by globally load balancing and caching content.

In addition to supporting thousands of production servers, the operations team supports hundreds of non-production servers in various environments from development to preproduction or staging, as well as dozens of infrastructure servers that support the site.

As shown in the following table, the reach of Microsoft.com into the total United States Internet audience surpasses all corporate sites and continues to grow at a rate of 6.9 percent since September 2004.

Table 1. Corporate Web Site Reach Rankings

The mission of the operations team that is responsible for Microsoft.com is to achieve the highest availability on the Internet while showcasing Microsoft technologies. The operations team has also developed a strategy to be an early adopter of many Microsoft products, and to provide valuable feedback to the product groups while sharing its best practices with Microsoft customers.

Over the last three years, Microsoft.com has achieved the number one ranking on the Internet in terms of site availability as measured by Keynote, the worldwide leader in e-business performance management services. Through its Keynote Global 35 monitoring service, Keynote measures availability by verifying that an entire page and all of its components are available at regular intervals from 35 locations around the world. If even a single image on the page is not available from any of the test locations, Keynote considers the site to have failed for that interval. The following table shows how Microsoft.com compares to other top-ranked industry sites that the Keynote Global 35 service also monitors. For more information about the Keynote Global 35 monitoring service, refer to the IT Showcase case study Monitoring and Troubleshooting Microsoft.com at http://www.microsoft.com/technet/itsolutions/msit/.

Table 2. Web Site Availability Rankings

Although the Microsoft.com site has grown continuously, experiencing unprecedented levels of availability and performance on 32-bit hardware and operating system platform, memory limitations inherent with the 32-bit platform presented the operations team with particular challenges. These challenges required frequent intervention and made it difficult for the operations team to troubleshoot and debug Web applications.

Microsoft.com Migration to 64-bit Web Servers

Because of the increase in the virtual memory addressing space, the Microsoft.com operations team was interested in evaluating the potential benefits of running www.microsoft.com Web servers on a 64-bit version of Windows.

Historical Challenges on the 32-bit Platform (x86)

The Microsoft.com operations team routinely monitors and analyzes a wide array of site-wide performance metrics, as well as the individual servers that support the site. By far, the number one bottleneck that the operations team identified for server performance on the x86 platform was contention for memory on the Web servers.

In 32-bit versions of Windows, the total virtual memory address space is 4 gigabytes (GB). By default, the operating system reserves 2 GB of that space for kernel mode processes and limits applications to the remaining 2 GB of virtual memory address space. When an application's virtual memory space becomes overcommitted or fragmented, the application can experience errors or performance degradation and may cease to function correctly. In IIS 6.0, when this situation occurs, the application pool must be recycled to return the application to normal performance levels.

For Microsoft .NET applications, the common language runtime (CLR) allocates memory in large contiguous blocks within the virtual memory address space. The CLR manages fragmentation inside its heap through a process called garbage collection, which periodically compacts its memory region to keep free memory inside the heap as a continuous block. Memory fragmentation occurs over time as CLR continually allocated and frees memory, leaving initially large contiguous blocks of free memory split up into many smaller blocks of free memory. Memory outside of the managed CLR heap is subject to this type of fragmentation. In combination with continually increasing memory consumption due to leaks, high number of loaded assemblies, and excessive use of ASP.NET caching, the usable virtual memory for the CLR is significantly reduced.

As memory usage continues to increase, and especially as it gets close to the usable limit, the garbage collector must work harder to satisfy allocation requests. Because the garbage collector runs at an elevated thread priority level, and as multiple applications on the same server reach their virtual memory limits, excessive garbage collector activities can render the entire server unresponsive for extended periods that increase over time.

It is possible to configure 32-bit versions of Windows to allocate 3 GB of memory to applications by using the /3GB switch in the boot.ini file. However, this action reduces the amount of memory allocated for kernel mode processes. In the case of high-traffic Web servers, the results of this action can be disastrous. High-traffic Web servers create and maintain thousands of concurrent TCP network connections, each of which requires an allocation of kernel memory resources. Although using the /3GB switch provides an additional 1 GB of virtual memory to applications, it limits kernel mode processes such as TCP connection management to 1 GB of virtual memory. Specifically, the operations team observed that the network stack frequently failed when using the /3GB switch, especially in TCP connection request attack scenarios known as SYN attacks.

In Microsoft Windows 2000 and IIS version 5.0, all Web sites and applications ran within a single, shared application environment with a single 2-GB allocation of virtual memory address space. This meant that any single, poorly performing application could in turn cause other applications to perform poorly, or cause the entire Web service on a server to come to a halt. The solution to such a situation was to recycle IIS or restart the server to start with a fresh, 2-GB virtual memory allocation. This action had the undesired consequence of removing the Web server from service for the duration of the recycle, and it flushed any cache that any of the applications on the server previously established.

Windows Server 2003 and IIS 6.0 introduced the ability for Web administrators to create custom application pools in addition to the default application pool for Web sites. Each application pool spawns dedicated worker threads in its own isolated allocation of virtual memory address space. By using application pools, applications may be segregated individually or consolidated into logical groupings. For example, a critical application may be placed in its own application pool to limit the possibility of another application adversely affecting its performance. Conversely, a known poorly performing application may be placed in a dedicated application pool to limit the possibility that it will adversely affect another application's performance.

When a particular application pool is not functioning properly or has reached the specified threshold for a forced restart, only that individual application or group of applications is taken offline and restarted. Most importantly, an application pool recycle action is performed by the operating system in a graceful manner. For example, before the application pool is taken offline, requests are queued while a new process for that application pool is instantiated to service all subsequent requests once it is online.

Note: App pools can be configured by administrators to restart based on time intervals or memory usage thresholds. The default setting is for the application pool to automatically restart every 12 hours. The Microsoft.com operations team prefers to use a virtual memory threshold setting of 2 GB instead of time intervals.

There is a practical limit to the number of application pools that should be created on a given Web server. At Microsoft.com, it was determined that the optimum number of application pools on a 32-bit server is 12. The Microsoft.com operations team considers applications that have gone through a full Software Development Life Cycle (SDLC) to be trusted code. All other applications, including many from partner organizations, are considered to be untrusted code. The Microsoft.com operations team separates trusted code from untrusted code by grouping like code together in application pools. Some critical applications or applications with known problems such as memory leaks may get a dedicated application pool. However, after reaching the optimum number of application pools on a server, the luxury of isolating an application in its own application pool was no longer an option, so most applications are in shared application pools. In general, the most problematic applications are in the untrusted application pool, but if an application causes other applications in the untrusted application pool to crash, the application is banned from the site until it is fixed by the developers.

Note: Web application developers can use the newly released Debug Diagnostic Tool, included in the IIS Diagnostic Toolkit, in conjunction with a application stress testing tool such as Application Center Test, included in Microsoft Visual Studio® .NET. to assist them in diagnosing memory leaks in IIS.

Although the ability to create independent application pools with isolated memory protection has yielded tremendous benefits to Microsoft.com, each individual application pool is still subject to the 2-GB virtual memory limitation, and the memory recycling intervals increasingly became shorter. Many applications or groupings of applications simply require more virtual memory than 2 GB to operate at an optimum performance level for an extended period of time. With a 2-GB memory limit, it can be extremely difficult to determine if an application actually requires more than 2 GB to function normally over time or if the application has a memory leak. Even with the ability to configure thresholds for automated application pool restarts, if they are occurring frequently, it can be a significant performance hit on a server. With the increased resource demands of complex ASP.NET applications, some of the application pools for Microsoft.com were recycling as often as every five minutes.

Note: When an application pool restarts, it must rebuild cache elements for the applications. This typically has significant impacts on performance. Administrators can configure Application pool restart behavior to orphan the old process so it can be debugged, but this method also has performance implications and may require the administrator to take the server offline temporarily.

With hundreds of increasingly complex applications running on the Microsoft.com Web servers, the challenges due to the virtual memory limitation only continued to increase.

Potential Benefits of 64-bit Versions of Windows

One of the primary differences between 32-bit versions of Windows and 64-bit versions of Windows is a vastly increased virtual memory space address that the additional bits afford. Windows for the x64-based platform uses 43 bits for virtual memory space addressing, which gives the kernel 8 terabytes of addressable memory and leaves the other 8 terabytes for 64-bit user mode processes. Because the operating system no longer has to share the 32-bit addressing space with kernel mode operations, the virtual memory address space for a 32-bit application is also increased from 2 GB to 4 GB, which is the total available 32-bit memory address space. These increases in available memory result in the practical removal of a memory limitation altogether for 64-bit applications, and potentially significant benefits for 32-bit applications as well. The following table summarizes the differences in memory limitations between the 32-bit and 64-bit versions of Windows.

Table 3. General Memory Limits

Note: For a 32-bit application to take advantage of the larger 4-GB address space, the /LARGEADDRESSAWARE flag must be provided to the compiler when an application is compiled. IIS 6.0 is configured with this flag by default when instructed to run worker processes in the Microsoft Windows-32-bit-On-Windows-64-bit, or WoW64 environment.

Microsoft introduced a 64-bit version of Windows with Windows 2000 in 2001. That first version was designed to run specifically on the Intel Itanium hardware platform, also known as Itanium. Although the 64-bit operating system and the subsequent Windows Server 2003 version for Itanium provided a vastly increased limit for virtual memory address space for applications, the platform is mostly aimed at and suitable for 64-bit applications. Like many of today's Windows Server-based applications, Microsoft.com Web applications are designed to run in 32-bit environments. In general, 32-bit applications do not perform as well on the Itanium platform as they do on native 32-bit platforms. In addition, the Itanium hardware can require a significant investment compared to x86 platform servers.

Since the release of the Itanium platform, both Intel and AMD have developed more economical 64-bit-capable CPUs based on 32-bit registers and 64-bit extensions, known as the x64-based platform. (Intel refers to its chip as the EM64T.) This design enables either a 32-bit or 64-bit operating system to be deployed to an x64-based server. Additionally, for the x64 version of Windows Server 2003, 32-bit applications run in the WoW64 environment, which enables them to run natively using the 32-bit registers with negligible performance impact. In fact, both 32-bit applications running within WoW64 and the 32-bit versions of Windows running on x64-based hardware often outperform a similarly configured 32-bit server. The Microsoft.com operations team observed no negative performance impact when running 32-bit applications on their x64-based hardware.

The ability to run a 64-bit operating system and overcome the virtual memory limitations of a 32-bit operating system, and provide comparable or better performance for 32-bit applications without code modifications is quite promising. Combined with potentially lower hardware cost, the x64-based hardware and operating system platform may offer increased performance at a lower price.

In light of the potential benefits, in March 2004, roughly one year in advance of the official release of the x64-based version of Windows Server 2003, the Microsoft.com operations team decided to evaluate the benefits of implementing servers built on the x64-based hardware platform by conducting proof of concept (POC) testing and then running prerelease versions of that operating system on production Microsoft.com servers.

Adoption-Strategy and Approach

Before performing thoroughly testing the new platform, it was important for the operations team to develop a standard configuration for an x64-based server similar to the existing configuration for 32-bit servers.

How Microsoft.com Started the Move to the x64 Platform

The www.microsoft.com Web site is served by 80 identically configured Web servers in 10 load-balanced clusters of 8 servers each using NLB. With such a high degree of redundancy, the operations team can add a server to or remove a server from a specific NLB cluster without affecting availability or performance of the overall site. By configuring an x64-based server with the same content, applications, and settings as one of the existing servers, the operations team can add the new server to an existing production cluster and monitor its performance.

Note: Administrators typically create an IP load-balanced NLB cluster with all cluster members actively servicing requests for a group of identically configured servers with relatively static content and data. Unlike failover clusters using the Microsoft Cluster Service, there is no requirement or need for shared storage among the servers in an NLB cluster.

The Microsoft.com operations team builds all Microsoft.com servers from a standard operating system image and then configures the server as a Web server by applying configurations scripts which ensures that team builds and configures all servers in the same way. For more information about Microsoft.com server configurations, refer to the IT Showcase note on IT Microsoft.com Standard Server Configurations at http://www.microsoft.com/technet/itsolutions/msit/.

To evaluate an x64-based server, the operations team created a standard Web server build, including the base operating system and a scripted Web server configuration. Build 1171 of the x64-based operating system was the first version that the operations team selected for deployment. The operations team then performed a POC test by using hardware supplied by AMD and the newly created standard server build. The operations team configured the POC server as described in the following table.

Table 4. x64-Based Test Server Configuration

The base operating system configuration includes all of the system tools and applications required for deployment into the data center. The x64-based version of Windows requires specific drivers for hardware devices and any tools or applications that include kernel mode access (such as antivirus). The operations team had to acquire and test the appropriate drivers to confirm functionality. After the base operating system image was configured and stable, the operations team incrementally tested various applications on the new platform in the test lab. This testing involved a considerable amount of time and effort because each identically configured Microsoft.com Web server hosts 350 virtual roots, 190 IIS Web applications, and 12 application pools.

In parallel with the POC, the Microsoft.com operations team purchased x64-based hardware to replace the 32-bit servers. As noted in the previous section, the x64-based platform can run either 32-bit or 64-bit versions of Windows. Initially, the operations team built the new x64-based servers with the standard 32-bit operating system Web server configurations and deployed them into production. At this point, the operations team also changed the architecture of the NLB clusters by increasing the number of servers in an NLB cluster from six to eight.

Upon completion of the POC lab testing, the operations team added the POC server to one of the production NLB clusters. The operations team observed the server while it handled live traffic as the final validation required to move forward with a full migration to the x64-based platform. The operations team then upgraded additional Web servers one at a time within that NLB cluster until the entire cluster was running at 64-bit.

The operations team typically makes upgrades to all servers in a given NLB cluster simultaneously. A global load balancing service allows entire NLB clusters to be temporarily removed from service during server upgrade activities. This process of upgrading all of the servers at once in an NLB cluster was repeated by the operations team on the remaining NLB clusters until all of the Web servers in a data center were running 64-bit versions of Windows. The process was then repeated at the next data center until all of the Web servers for www.microsoft.com were running 64-bit versions of Windows.

The NLB clusters could be migrated to the new x64-based standard build one at a time because the production servers were already running on x64-based hardware. This migration approach enabled a smooth, phased migration that did not affect production capacity or performance. This phased approached also allowed for a rollback strategy at a granular level. If an individual server encountered issues, the operations team could quickly remove the server from the cluster, and then rebuild the server as either a 32-bit or 64-bit server.

Transition Experience

One of the biggest concerns of the Microsoft.com operations team before the project began was the amount of work that would be required to modify applications and components to function properly on the x64-based operating system. The operations team quickly realized that if configured properly, the WoW64 emulation environment would virtually eliminate the need for any modifications. Specifically, the operations team did not need to touch a single line of code or recompile any of the following components or applications:

• 32-bit Internet Server Application Programming Interface (ISAPI) filters

• Older Component Object Model (COM) components

• Microsoft ASP.NET version 1.1 applications

The operations team also confirmed that the 32-bit applications performed with negligible differences between the two platforms as a result of the 32-bit registers in the x64-based CPUs.

Side-by-Side Hosting of 32-bit and 64-bit Applications

Although the operations team can migrate the hardware and operating system platforms completely to 64-bit, there are still many dependencies on 32-bit application components that require IIS to run 32-bit worker processes under WoW64. Many of the applications are written in ASP.NET 1.1, which uses the Microsoft .NET Framework version 1.1, and that version is not 64-bit capable. Likewise, ISAPI extensions and filters, along with custom and older COM components that have been compiled over the years, require 32-bit processes.

Therefore, the operations team needed to configure IIS to run worker processes for the application pools in the 32-bit WoW64 environment. For instructions on how to configure an IIS metabase key that instructs IIS to use 32-bit worker processes instead of the native 64-bit worker processes, see Knowledge Base Article "Windows Server 2003 SP1 enables WOW64 compatibility for 32-bit Web applications in IIS 6.0" at http://support.microsoft.com/?id=895976. By default, IIS is configured to take advantage of the full 4-GB address space for application pools when it operates in 32-bit mode.

When IIS is configured to run in 32-bit mode, all processes run in that mode. Microsoft does not support or offer a means to run both 32-bit and 64-bit applications within IIS application pools on the same physical server. It is now possible to develop applications in Microsoft ASP.NET version 2.0, which uses the 64-bit-capable Microsoft NET Framework version 2.0. To service these native 64-bit Web applications, an separate Web server configuration that runs IIS in native 64-bit to host these applications would be required.

Note: IIS version 7.0 will provide a supported method to run both 32-bit and 64-bit worker processes simultaneously on the same server.

Benefits

The Microsoft.com operations team observed many benefits by migrating to the x64 platform. The immediate benefits were significant improvements in individual Web server and overall Web site performance.

Performance Gains

The Microsoft.com operations team observed two major performance gains from migrating the Microsoft.com Web server to the x64-based platform. The first gain was a significant drop in CPU utilization due to less frequent or eliminated application pool recycling. The operations team also observed that application pools would no longer recycle at all or would recycle at a rate of weeks instead of minutes. The performance implications of this were significant. The following Performance Monitor charts show a decrease in CPU usage of approximately 50 percent.

Figure 1. 64-bit server processor utilization

Figure 2. 32-bit server processor utilization

In addition to the 50 percent decrease in CPU utilization, the 32-bit servers experienced noticeable spikes in which the CPUs were utilized at 100 percent for sustained periods of time. The operations team determined that a spike occurred when one or more application pools ran out of virtual memory and recycled. On the x64-based servers, these spikes do not exist because the application pools are no longer running out of memory.

The second major performance gain, and arguably the most important, was significantly improved response times for applications. This gain directly leads to an improved end-user experience. Because the servers no longer have to queue or maintain open connections for recycling or poor performing applications at or near their 2-GB virtual memory limit, the servers can respond much faster and more consistently to requests, as shown in the following table.

Table 5. x86 Versus x64 Response Times

The operations team observed the biggest response time increases for what historically were the worst performing applications. The performance gains for those applications were substantial, as shown in the following table.

Table 6. Worst-Performing Applications

Note: The Microsoft Server Performance Advisor (SPA) that the Microsoft.com operations team used to generate these numbers is available as a free download on Microsoft.com at http://www.microsoft.com/downloads/details.aspx?FamilyID=61a41d78-e4aa-47b9-901b-cf85da075a73&DisplayLang=en

Hardware Consolidation

It is easy to conclude that there is great potential for Web server consolidation in conjunction with a migration to the x64-based platform. Theoretically, Microsoft.com could reduce its number of Web servers by 50 percent. However, the operations team elected not to reduce the number of Web servers because the operations team wanted the servers to run at the lower, more consistent utilization levels, and the team wanted to maintain the additional capacity as the site continues to grow. This additional capacity also provided full data center redundancy without increasing the number of servers. Prior to moving to the x64-based platform, an entire data center outage would have resulted in diminished performance for the duration of the outage. On the x64-based platform, the performance of the site will remain relatively stable in the event of a single data center outage.

Web Application Behaviors

With a 2-GB address space, it was extremely difficult to differentiate between an application that was leaking memory and an application that was simply using large amounts of memory as part of normal behavior such as caching. With the increase of available virtual memory to 4 GB, the memory usage for the latter category of applications generally reaches a plateau somewhere between 2 GB and 3 GB. This additional virtual memory makes it far easier to identify an application that is actually leaking memory because its memory usage will continue to climb to the 4-GB limit. An IT team can observe the application for longer periods of time, which aids in the eventual debugging of the application.

The x64-based platform also provides the ability to create more application pools, which leads to further isolation of code and content among the various Web applications.

In the future, applications written in ASP.NET 2.0 will further improve reliability and performance because they can address 8 terabytes of virtual memory and can execute in the native 64-bit operating system environment. ASP.NET and the .NET Framework 2.0 also provide enhanced diagnostic and debugging capabilities.

Best Practices

The most obvious and important best practice that the Microsoft.com x64-based Web server migration effort revealed is to migrate high-volume Web servers to the x64-based hardware and software platform. Any organization considering such a migration should conduct a POC to confirm performance gains and identify any code migration dependencies.

When doing so, the Microsoft.com operations team recommends the following best practices based on its experience.

Verification of Third-Party Dependencies

An organization should fully understand any third-party dependencies and the availability of x64-compatible versions of applications and drivers. As part of any platform migration, an organization must verify and ensure that any third-party dependencies in the environment are compatible with the x64-based operating system. Any component that requires a kernel mode driver needs to have an x64-based compatible driver, because 32-bit kernel mode drivers cannot be used on the x64-based operating system. Some of the dependencies that the operations team encountered included the following:

• Antivirus software

• Backup software

• Imaging and deployment software

• Common administrative tools that use filter drivers such as Filemon and Regmon

Scripting Behavior

An organization should fully understand scripting dependencies in order to know which script host to use in particular circumstances. Scripts that depend on 32-bit com objects will require 32-bit cscript or wscript scripting host versions located in the %systemroot%\SysWow64 folder. The organization should specifically reference this path when launching the scripting host. If not, the default 64-bit versions of the scripting hosts will be launched. An alternative is to change the default scripting hosts to be the 32-bit versions.

Scripts using 32-bit scripting hosts also need to be aware of WoW64 redirection behaviors, as discussed in the following section.

WoW64 File System and Registry Redirection Behaviors

An organization should become familiar with the WoW64 redirection behaviors that occur in both the registry and file system. These redirection behaviors are designed to help 32-bit processes work in the 64-bit environment.

File system redirection

In the x64-based operating system, any time a 32-bit process attempts to access %systemroot%\system32, the WoW64 layer automatically redirects it to %systemroot%\syswow64, which contains all of the 32-bit Windows binaries. This prevents a 32-bit process from trying to load a 64-bit binary.

Registry redirection

Similar to the file system redirection, the same behavior exists for accessing the registry. Any 32-bit process that attempts to read or write to HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node\. This behavior enables separate configurations to be maintained for 32-bit and 64-bit processes. Any custom settings or keys that are set in this node may need to exist in both keys, because a 32-bit process will be redirected to this new branch.

Conclusion

Microsoft.com is one of the busiest yet most highly available Web sites on the Internet. Even though the Microsoft.com site has grown continuously on the 32-bit platform, and it has enjoyed unprecedented levels of availability and performance, memory limitations inherent with the 32-bit platform presented the operations team with particular challenges. These challenges required frequent intervention and made the troubleshooting and debugging of Web applications difficult.

The strategy of the Microsoft.com operations team to be an early adopter of Microsoft technologies made the decision to evaluate the benefits of increasing virtual memory limits by implementing servers built on the x64-based hardware and software an easy one. The project started with a proof of concept and quickly progressed to running prerelease x64-based versions of the Windows operating system on production Microsoft.com servers. With the seamless migration of 32-bit applications that key features of both the x64-based hardware and the operating system afforded, the operations team could achieve 100 percent migration success by the time Microsoft released the x64 version of Windows.

After completing the transition to the x64-based platform, the memory limitations that the operations team had been struggling with for years evaporated. The resulting benefits of the elimination of the memory contention problems will allow Microsoft.com to continue to set the industry standard for availability while greatly increasing both current end-user performance and future capacity. The new platform also enables the next wave of 64-bit Web applications written in ASP.NET 2.0 by means of the 64-bit-capable .NET Framework 2.0. The performance of these applications running in a native 64-bit environment is expected to be even better than that of 32-bit applications running on the x64 platform.

A main purpose of this white paper is for the Microsoft.com operations team to share important lessons learned and best practices. In the case of high-traffic Web servers, however, the most evident lesson from this white paper is that a migration to the x64-based platform can yield tremendous benefits with a seamless migration path, while providing significant potential to realize immediate savings in hardware and operations costs.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase