32 Bit ASP.NET application on 64 Bit Amazon instance

I have an web application which is written in asp.net mvc2. Currently running on amazon ec2 32 bit开发者_开发百科 medium instance. Because of huge traffic we want setup multiple instance. But before this we want to run application on 64 bit instance.

Any recommendation, proof of concepts, roadblocks etc?

Since this will be 64 bit windows, you will also have a 64 bit IIS instance. If you have any third party libraries that use less common components (like Mono), you might need to recompile them from source or make some changes. For instance, we ran into this when we started hosting in 64 bit IIS:

System.BadImageFormatException on running ServiceStack examples.

This probably won't be too much of an issue for you if your app is all .NET and you aren't using libraries that use native code.

You can also run IIS worker processes as 32 bit applications, so it should be very plug and play even if you run into issues: http://forums.asp.net/p/1156811/1901796.aspx

I recently switched a bunch of 32 bit IIS hosts to 64 bit and there weren't too many issues.

There are a few things to check, but mostly it should just work:

1. Make sure all of your assemblies are compiled to 'Any CPU'.
2. Check any 3rd party assemblies that might not be 64-bit compatible.
3. If there is any COM Interop / PInvoke in your application, it needs to be 64-bit friendly (like memory alignments, etc), using IntPtr instead of Int32 in the case of addresses.
4. If it doesn't work out, you can stay on the 64-bit Operating System and just change your AppPool to use WOW.
5. Try it. It's easy to spin up a new EC2 instance.

I supose one other thing that people mention when switch to 64-bit is they think something is wrong because the Application is using more memory than it did when it was 32-bit. This is often caused by "pointer bloat". Addresses are now 64-bits wide as oppose to 32-bit.

In some other more extreme cases, since the x64 and x86 .NET Framework have different JITers, the x64 is optimized differently, and can hurt performance rather than improve. This was a larger problem for the .NET Framework 2.0 when left unpatched.