ASP.NET performance decrease between 32bit/64bit server

Most modern 32-bit CPUs support PAE which allows them to address more than 4GB of physical memory, although a single process can only see 4GB at a time. The kernel will take some of this address space. This Stackoverflow post discusses how PAE works.

Many operating systems (including Linux and MS Windows) offer an API that allows you to manipulate the MMU and page overlays in and out of the virtual address space of a process. This facility allows you to use extra memory for disk buffers. However, as far as I am aware the only DBMS platform with direct support for this is MS SQL Server.

Additional memory will improve your database read performance (which will probably improve your overall throughput), but write performance will be constrained by I/O. If you have a low DB cache hit rate (say less than 95%) then additional memory will probably improve your overall throughput. Otherwise, you may need to look at your disk subsystem (see 1 below).

Assuming you need or can benefit from more memory, the best approach is to move to a 64 bit platform. A modern Xeon or Opteron server will let you install up to 32-144GB depending on the model. This is likely to be your best option.

1. SANs are good for transactional applications. For a high-volume application you should have write-through caching on the DB logs but you may be able to get away with write-back caching on the data volumes. This will get you good log-reader performance as the random data writes can be absorbed by the controller's battery-backed cache and the controller can optimise disk writes to improve throughput.
   
   However, this arrangement has failure modes that can leave the data volumes inconsistent (corrupted). Using write-through on the log volumes mitigates this (as the logs are not vulnerable to these failure modes). Practicaly this limits you to a restore/roll-forward recovery model, so it will only work if you can tolerate a (say) 4-hour recovery window.

There are various things to check when asp.net starts acting all funky. Checking to make sure the extensions are allowed is one, though you usually end up getting 404 not found errors rather than other sorts of failures (this is an intentionally bogus error designed to avoid leaking information to potential hackers).

However, most sorts of troubleshooting eventualy come down to reinstalling the .NET Framework and then running aspnet_regiis.exe to reset everything. There shouldn't be any differences between IIS on 2k3EE vs 2k3SE.

Also, remember that IIS isn't PAE-aware so even if you do have tons of RAM on your box, you might still have problems taking advantage of it in any given app pool.