What are the pros and cons of running IIS as 32bit vs 64bit on a 64bit OS?

Question

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?

Answer 1

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).

Answer 2

Because how 32bit and 64bit are isolated on Windows, you cannot load a 32bit dll in a 64bit process.

Therefore, sometimes 32 bit IIS worker process is a must if you have 32bit only legacy libraries. (There is at least one way to load 32bit dll indirectly into a 64bit process but I usually ignore that complex approach.)

Since Microsoft may only ship x64 version of Windows Server soon, you should really consider upgrade that 32bit library to 64bit or get rid of it completely by rewriting in 64bit.

After all, 64bit can provide you some advantages.

Answer 3

I hear you lextm, but unfortunately the library is a 3rd party dll from our backend warehouse fulfillment system vendor. We only talk to them in one spot on the site, but we can't currently get around it. We've asked repeatedly for a 64bit version but their development cycles tend to be measured in years, not weeks/months, so it will probably be a while.

We may try to go down the dllhost route for that one library to take it out-of-process as you suggest, but I haven't gotten all of the details figured out on that complex approach yet, and so we may avoid it for the time being.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.