IIS, ASP.NET and 64-bit performance considerations
32-bit computing platforms treat physical memory addresses as 32-bit integers. A byte-addressable 32-bit computer can address 4 gigabytes of RAM directly. It’s possible to put more than 4 gigabytes of RAM into an x86 computer and have it recognized by the operating system, but on 32-bit platforms, that memory is still made available to individual applications in much smaller pieces.
Even with a 32-bit OS such as Windows Server 2003 Enterprise Edition running on a computer with 32 gigabytes of RAM, there is still a hard limit on what an individual process or application can use. On Windows, this limit is roughly 2 gigabytes of RAM per running process, no matter how much physical RAM is installed. This is where the 64-bit OS shines, even with 32 bit apps.
A 64-bit computer such as an AMD Opteron-based server or an Intel EM64T-based server can theoretically address 2 64 bytes (16 exabytes) of RAM. As of today, this means the memory addressability is essentially unlimited on 64-bit hardware. Current implementations of Windows Server 2003 64-bit now support up to 1 terabyte of physical memory (Standard Edition supports 32 gigabytes) installed on a 64-bit computer. Of course there are very few mainstream computers today where you would need 1 terabyte of RAM, considering this is 1,000 gigabytes of RAM. With a total virtual address space of 16 terabytes on Windows 64-bit platforms, an individual process on Windows Server 2003 (if it needs it) can now use up to 1 Terabyte of RAM directly, or 500 times more RAM than available to an individual process on 32-bit Windows. And when you look at the various options available to you and how much "bang for the buck" you can get from each of them in terms of performance enhancement, buying more RAM has the best cost to benefit ratio of almost anything.
However, to exploit the additional available RAM, the full software stack must also be 64-bit capable. This means for .NET, the .NET CLR must be 64-bit aware, and for Java, the JVM must be 64-bit aware. With .NET 2.0, Microsoft delivers 64-bit support with .NET for the first time. With a 64-bit OS and a 64-bit runtime, .NET 2.0-based applications can now utilize 500 times more memory for data such as server-based caches.
According to a recent article on MSDN, the performance benefits seen from the x64 OS have been substantial. Because of the larger virtual memory space available to the IIS worker processes, server performance has improved dramatically. In certain cases the memory usage of application pools that were previously recycling every five minutes leveled off and stopped recycling altogether. Meanwhile, poorly behaving applications that were leaking memory or abusing the ASP.NET cache could be identified. Before the migration, with a 2GB address space it was extremely difficult to differentiate between an application that was leaking and an application that was simply caching as part of its normal behavior.
There are 232 possible combinations that a 32-bit address can take (meaning 4GB worth of addressable space). On the x86 operating system, half of that is allocated for the kernel, and the other half is given to user mode processes such as IIS worker processes. Since the addressing spaces of the user mode processes are independent of each other, each process can reference up to 2GB of memory.
On the x86 platforms, the 3GB switch, which gives 3GB of virtual address space to the user mode processes and only 1GB to the kernel, is a workaround. But the results, according to the writers, were disastrous. Giving the kernel only 1GB just wasn’t enough for the networking stack to keep up on the test servers. Also, in attack scenarios (such as SYN attacks), there wasn’t enough pool memory for TCP/IP to fend off even the smallest attacks.
The x64 architecture changes all of this, even while running 32-bit IIS worker processes. With a 64-bit addressing space, there is a possibility of 264 unique address combinations (16 exabytes). The x64 OS currently uses 43 bits for addressing, giving the kernel 8TB of addressable memory, and leaving the other 8TB for user mode processes.
Since 32-bit processes no longer need to share half the addressing space with the kernel, they are given the full 4GB addressing space to use running under WoW64. This means systems can run with a native 64-bit kernel and 32-bit IIS worker processes that get 4GB of addressing space, instead of 2GB on the x86. That's a big boost in performance even while staying with 32 bit enterprise server - type apps.
Processor utilitzation also saw a dramatic improvement in performance. Because the application pools were no longer recycling, or were at least recycling at a rate in the range of weeks rather than minutes, the performance implications were significant.
The average processor utilization in the MSDN article tests of the x64 server was only about half that of the x86 server (34 percent versus 64 percent). On the x86 server there were 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. However, on the x64 server these spikes didn'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 improved and content was delivered to the clients much more quickly.
Bottom line? Going 64-bit is the cheapest and easiest way to get more "bang" out of your applications, especially if you are using .NET.