8

Besides the advantages of 64-bit memory allocation (> 4 GB - see this question on StackOverflow for why 32-bit +4 GB solutions won't work for me), what other reasons do I have for recommending that we should host an ASP.NET website on 64-bit Windows Server 2008, as opposed to the 32-bit version?

If it's only the larger addressable memory (>4 GB) issue, we have a load-balanced solution anyway so we could scale by adding a new (virtual) box.

The CPUs won't be running hot either, so any marginal speed gains couldn't be justified.

My own gut feeling is that we should host on 64-bit if we can, purely because it's easier to scale (by plugging in more RAM when we need to). But is that it?!

All comments and ideas are welcome!

Community
  • 1
Duncan
  • 325
  • 2
  • 6
  • 11
  • Shared or dedicated? Significant differences in your web site configuration on a shared server... – Christopher_G_Lewis Jul 08 '09 at 18:29
  • possible duplicate of [What benefits are there to running a 64-bit Operating System?](http://serverfault.com/questions/1938/what-benefits-are-there-to-running-a-64-bit-operating-system) – ThatGraemeGuy Jun 02 '10 at 21:48
  • Actually MS recommends running ASP.NET apps in 32 bit mode ON A 64 BIT OPERATING SYSTEM. 4g of 32 bit are a bad limit as it counts towards the system. On a 64 bit system you can have more than 4 gb and the apsp.net uses part of it. Caching etc. can be done outside. – TomTom Apr 13 '11 at 06:33
  • @TomTom is this recommendation still true today? If so, do you have a reference for it? – Ohad Schneider Dec 04 '16 at 14:59

7 Answers7

15

I think the question you should be really asking is why not go x64? If your hardware is supported and your apps work, what's the reason to stick with 32 bit? There is little to no cost difference and its the way all future software is going to move, Exchange 2007 for example is 64bit only and I'm sure many new pieces of software will go that way.

If you can't come up with a compelling reason to stick with 32 bit then I'd go with 64.

Sam Cogan
  • 38,158
  • 6
  • 77
  • 113
12
  • x86_64 cpus do have the no-execute bit in their page tables. I.e. this can prevent security exploits caused by buffer overruns. 32-bit x86 cpus do only support this feature in the PAE mode.
  • you can only used signed Windows drivers. IMHO this is an advantage because you can't break your system with a broken, untested driver. Remember, most Windows problems are caused by broken drivers.

To be honest: In my opinion 64-bit should be the default for years now! I can't believe how long it takes the Windows community to make the switch. I can't understand why Microsoft even bothered to release a 32-bit Vista (and now even Windows 7). Even Apple decided to switch from PowerPC to 32-bit x86 although most cpus at the time were already capable of 64-bit. This makes no sense to me at all. Everything would be so much easier if everything would be 64-bit and only 64-bit.

knweiss
  • 3,955
  • 23
  • 20
  • +1 this answer points out some of the "unknown" features of 64bit Windows over 32bit. – Matt Jul 07 '09 at 22:24
  • Signed drivers can be a pain in the ass when you need to get some hardware working, and Windows decides not to install the driver because it's no signed, even if it works fine. – Dentrasi Jul 01 '10 at 08:33
  • 1
    Which is pretty much a non issue on a server, especially a virtual one ;) IOt is more common on desktops, but serve level hardwae ALL has signed drivers. – TomTom Apr 11 '11 at 08:34
4

There are lots of "reasons" but the first and foremost is that all of Microsoft's products are going x64. It 'future-proofs' the design a bit, and gives your ASP.NET apps more room to fail (from an OOM error, for example).

Jeff Costa
  • 481
  • 3
  • 9
4

This is not ASP.NET-related, but I'll add for the sake of completeness. Some Microsoft Server products, like Exchange Server 2007, run only on 64-bit Windows platforms. I think you could call that a benefit.

splattne
  • 28,348
  • 19
  • 97
  • 147
2

I don't think there is a dramatic cost difference between either one, so why not just deploy the new server with Windows Server 2008 64-bit? The ability to utilize its greater memory capacity is the best (and only that I know of) reason to use it. With memory so cheap nowadays, 4 GB just seems so little for a new server!

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Russ Warren
  • 1,304
  • 10
  • 21
1

There are about 10 great answers to this question in this recent RunAs Radio podcast on 64-bit computing.

One thing mentioned is that the bus width is doubled, and therefore can read/write data faster. The performance boost is slight vs. 32 bit for home use perhaps, but certainly well worth it for a server.

p.campbell
  • 4,397
  • 6
  • 40
  • 51
0

There is an obscure (but real) bug similar to Y2K that affects most 32-bit machines. It is due to the unix epoch, used in some windows programs also, having a maximum value of sometime in the year 2038. At which point it will wraparround to 1901!

See Wikipedia "The year 2038 problem"

Relevant to this question because it affects 32-bit machines that use a standard machine sized variable for storing the unix epoch. It will be solved by the upgrade to 64-bit.

unixman83
  • 1,912
  • 8
  • 25
  • 33