38

Possibly better suited for "Rack Overflow", but from a developer's point of view, what are the advantages and disadvantages of running IIS (serving both legacy classic ASP and .NET) as a 32bit process instead of a 64bit process on a 64bit windows host?

The main advantage of 32/64 (iis/server) over 32/32 seems to be the ability to go up to 4gb in memory per IIS process.

The advantages I expect of 32/64 over 64/64 appear to be that it's easier to access legacy 32-bit in-process DLLs (of which we still have one from a partner vendor we can't move away from immediately) and perhaps a smaller memory footprint for the same code given smaller memory pointers.

Are there any performance benefits of 64/64 over 32/64 or anything else that would warrant a full switch now? Have I made any false assumptions here?

Gan
  • 4,327
  • 3
  • 30
  • 45
entropi
  • 519
  • 1
  • 5
  • 7
  • **Related post** - [Target 32 Bit or 64 Bit native DLL depending on environment](https://stackoverflow.com/q/23215518/465053) – RBT Apr 17 '18 at 06:25

5 Answers5

37

The only perf advantage to running IIS on 64bit vevrsus 32-bit is to allow access to a much larger memory address space.

If you are doing normal ASPX page processing, then it's likely you don't need to address more than 4gb from any single process. Suppose you run in 32-bit mode with a web-garden with multiple worker processes on the same machine. In that case each process can address up to 4gb.

The big advantage can come when you perform caching. A 64-bit process can maintain a huge in-memory cache (assuming you have the 32GB or more of RAM to support it) to allow you to cache complex page content or data, on the web server. This allows perf gains when the data is more expensive to generate than it is to retrieve - for example if the data is an elaborated form (let's say the result of a monte carlo simulation), or if the data resides off-box and the network IO time is much more expensive than cache-retrieval time.

If you do not use caching, then 64-bit IIS is not going to help you. It will require 64-bit pointers for every lookup, which will make everything a little slower.

64-bit servers are much more effective when used for databases like SQL Server, or other data management servers (let's say, an enterprise email server like Exchange), than for processing servers, such as IIS or the worker processes it manages. With a 64-bit address space, servers that need to manage data can keep much more of that data in memory, along with indexes and other caches. This saves disk IO time and elaboration time when a query comes in. Most Web apps don't need to address more than 4gb from a single process.


Maybe a useful analogy: In transport, an large SUV is like a 64-bit machine, while a regular, compact passenger car is like a 32-bit server. You can carry much more stuff in a large SUV, and it has a larger towing capacity, seating for 8 people, and a GVWR of 8600 lbs. But with all that, you pay. The truck is heavier. It uses more fuel. If you are only carting around 2 people and one duffel bag, you don't need an SUV. You'll be better off with the smaller vehicle. It can be speedier and more efficient.

Cheeso
  • 180,104
  • 92
  • 446
  • 681
  • 2
    Your analogy is flawed. X64 processes will perform faster than thunked 32-bit on 64-bit. Especially on older IA64 processors where there was noticeable overhead in thunking. – Roger Johnson May 26 '14 at 20:18
  • Yes. Except for some memory/pointer intensive apps, most applications can take advantage of the larger number of registers in x86_64 http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1 – phuclv Jun 10 '14 at 04:09
4

I don't think you've made any false assumptions. But I'd say, no, there's likely to be no performance difference between any of the scenarios you outlined. 32 on 64 on Windows does not operate at a penalty. 64 on 64 may give some slight performance boost, but that's dubious. There may be some memory savings with a 32-bit process, but this is likely negated by the thunking required to run the process in the first place.

The only benefit is the DLL issue you mentioned. That could be a reason for upgrading as well (if you have something specifically 64-bit that you need to use).

TheSmurf
  • 14,671
  • 2
  • 37
  • 47
  • What about the extra registers available when running a 64 bit process? Those should improve the performance of an application. – LanceSc Feb 03 '09 at 20:35
  • If Windows doesn't use the extra registers on behalf of the 32-bit process, then yes, there probably is a gain there. I don't know enough about the lower-level stuff to answer that question. – TheSmurf Feb 03 '09 at 21:33
  • 4
    re: *64 on 64 may give some slight performance boost, but that's dubious.* There's no magic performance boost just for using 64 bits. In fact there is a per-instruction tax that you pay, if you are in 64-bit mode. Every pointer move is 64-bits wide, every comparison is wider. These things can take MORE cpu cycles than the 32-bit counterpart. 64-bit only makes performance sense if your app needs to access a memory space larger than 4gb. In other cases, it costs more. – Cheeso Jan 14 '10 at 02:04
  • 4
    http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/ FYI from http://blogs.msdn.com/b/cenkiscan/archive/2012/06/20/iis-best-practices.aspx – Josh Jun 25 '12 at 14:02
3

I've had an experience where moving from a 32bit Windows 2003 Server to a 64bit Windows 2003 Server both running IIS 6 and the performance of the ASP.NET 3.5 website was unacceptable.

The 64bit server would run a clear 2 seconds behind the 32bit one consistently.

After switching IIS 6 to run as a 32bit worker process, the performance was equal and comparable once again.

I haven't verified it, but I think it might only apply to IIS6 win2k3, as testing I've done with IIS7 x64 (Vista) and a 64bit IIS worker process seems to perform just fine.

The process to swap to the 32bit process was quite simple. Here is the KB article with the supporting details: http://support.microsoft.com/kb/894435/en-us

ASP.NET 2.0, 32-bit version To run the 32-bit version of ASP.NET 2.0, follow these steps:

  1. Click Start, click Run, type cmd, and then click OK.
  2. Type the following command to enable the 32-bit mode: cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
  3. Type the following command to install the version of ASP.NET 2.0 (32-bit) and to install the script maps at the IIS root and under: %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
  4. Make sure that the status of ASP.NET version 2.0.50727 (32-bit) is set to Allowed in the Web service extension list in Internet Information Services Manager.

See the KB article for setting back to 64-bit.

Dave Transom
  • 3,865
  • 3
  • 18
  • 20
0

For memory availability, refer to this msdn blog.

Memory availability. For my application, we got what we needed switching from 32 bit process on 32 bit OS to 32 bit process on 64 bit OS, without the trouble of replacing 3rd party libraries. So, we stopped there. Benefits are: 1) 2-3x effective memory available to each IIS worker process and 2) In a 32 bit OS where the web site uses a lot of memory, other system processes and web sites compete for limited total memory. For your application, look at how much memory do your worker processes use. If each WP isn't using a lot of memory (well over 1GB), 64 bit worker processes won't help much.

For performance, I think you have to test your own applications in both configurations. Dave's post above indicates that you might have performance degradation with 64 bit. As cheeso notes, some applications may see benefits from caching (2GB + of cache is a lot, though). Except for limited and simple applications, I don't think we are going to be able to make performance generalizations. We might be able to point to specific technologies that perform better or worse.

Community
  • 1
  • 1
Precipitous
  • 4,925
  • 4
  • 25
  • 33
0

Besides the obvious memory differences, 32 bit processes on a 64 bit OS have to run in something called "Windows on Windows" or WOW mode. It's basically a thunking/emulation layer. There is a performance penalty if you pay close enough attention.

Terry Mahaffey
  • 11,079
  • 32
  • 44