Here is a great article from Microsoft that points out the benefits of 64 bit computing and how aside from the potential need to recompile, there are few problems with running 32-bit applications on 64-bit computers. The OS, Windows Server 2003 x64 is what makes this possible.
Here is a graph and and excerpt of the article:
There are two things of interest to note in the CPU utilization graphs. First, the average processor utilization of the x64 server is only about half that of the x86 server (34 percent versus 64 percent). Second, on the x86 server there are noticeable spikes where the CPU was running at 100 percent capacity for a sustained period of time. This was due to one or more app pools recycling because they had run out of virtual memory. On the x64 server these spikes don’t occur because the app pools don’t run out of memory.
The impact of this on the rest of the server is huge. Application response times improve and content is delivered to the clients much more quickly. Using the Microsoft® Server Performance Advisor, it becomes obvious that this is the case when you look at the response times of the different components of our site (see Figure 6).
The Server Performance Advisor (SPA) used to generate these numbers is available free at Microsoft Windows Server 2003 Performance Advisor.
All in all, the key things to remember from this migration include the significantly improved application response times thanks to larger virtual memory space on the x64 platform, the significant drop in CPU utilization due to less frequent recycling, and the server consolidation made possible by better performance on each server.
As with any platform migration there are sure to be hiccups or unexpected scenarios while validating the new platform. Take a lesson from our experience and remember to always verify and ensure that any third-party dependencies are compatible with the x64 operating system. Also ensure that any component that requires a kernel-mode driver has an x64 compatible driver, because x86 drivers cannot be used on the x64 operating system.
In addition, MSCOM had to verify the compatibility of third-party products like antivirus software, backup software, imaging and deployment software, and common administration tools that use filter drivers (such as filemon, regmon, and so on). So when you consider migration, keep these dependencies in mind.
Be sure to fully understand any third-party dependencies and the availability of x64 compatible versions. Become familiar with the WoW64 redirection behaviors that occur in both the registry and file system, and understand script dependencies so you know which script host to run it with, as explained in the sidebar "Redirection Behaviors and Dependencies."
After transitioning to the x64 OS, the memory limitations that MSCOM struggled with for years suddenly were eliminated. At the time of this writing, Microsoft.com is running the 32-bit version of IIS and ASP.NET running on Windows Server 2003 x64 Edition, and enjoying all the benefits.
The ongoing transition to the x64 platform in our environment is easier because the hardware and software migration is easier. The migration steps outlined here allow for a phased approach that enables proper testing, while letting you capitalize on the x64 hardware investment immediately.
This migration is merely a stepping stone in a transition to running in a native 64-bit x64 environment. Still, this configuration has already yielded tremendous results. In addition, as we migrate to the newly released ASP.NET 2.0, we will be able to run certain applications in a full native 64-bit IIS worker process, increasing available virtual memory from 4GB to 8TB. I think we’ve only seen the beginning of what the x64 platform has to offer!
