IIS, ASP.NET and 64-bit performance considerations
Now that 64-bit OS versions and machines to run them are widely available, developers are seeing that the biggest benefit of using the 64-bit platform is its ability to break through the memory addressability limitations of 32-bit platforms and allow applications to utilize much more memory. This can be particularly important for the performance of servers that potentially serve thousands of concurrent users and manipulate large amounts of data and/or potentially cacheable files on disk. This includes database applications (such as SQL Server), mail servers such as Exchange, terminal-server based Windows applications, and with . NET 2.0 64-bit, middle tier . NET applications that can cache or otherwise need to manipulate large amounts of data in-memory on the middle tier, including ASP.NET Apps.
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.
64-Bit Benefits
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.
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.
64-Bit Benefits
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.
... unless you're running Winforms in which case you can expect complex forms to load on an order of 8X slower than 32 bit .NET applications.
ReplyDeleteAnd if you force 32bit on a 64 bit OS you'll get artificating on GDI+ drawing.
NICE. :<
I'm not talking about any of that kind of stuff here. This is about high-performance services such as IIS, SQL Server, and .NET apps that use heavy duty memory intensive caching. You would never even see an Windows Form in any of this stuff, much less any GDI+. So let's compare apples to apples, OK?
ReplyDeleteYep,
ReplyDeleteI use 2003 x64 Enterprise, and I have to use a modified version of Denis Bauer's switcher.
IT seems that many current applications that have web integration simply do not see IIS as installed on 64bit machines - i am having to reinstall multiple servers with 32bit just because the web applications do not even install on 64bit!
ReplyDeletex64, it reminds me of similar problems i had about 12 years ago with Dec Alpha technology
i am using windows server 2003 64 bit r2. however, there is no option for asp.net in the iis. please help.
ReplyDelete