These tips are reasonably well-known and have been blogged by others. However, considering how often I come across these common “mistakes”, I felt yet another blog post was worthwhile:
1) Disable ASP.NET debugging in production!
I cannot emphasize this enough, Set debug=”false” in all your web.config’s. I’m regularly pleasantly surprised by how many production issues can be resolved by simply disabling ASP.NET debugging.
815157 HOW TO: Disable Debugging for ASP.NET Applications
http://support.microsoft.com/kb/815157
More info on the “evils” of having ASP.NET debugging enabled in production environments is discussed in the following blog post by one of my colleagues:
http://blogs.msdn.com/tess/archive/2006/04/13/asp-net-memory-if-your-application-is-in-production-then-why-is-debug-true.aspx
2) Store session state out of process
ASP.NET applications can encounter OutOfMemoryException’s (OOM’s) and other undesirable symptoms when .NET is struggling to allocate virtual memory. Busy sites that store session state in process are likely to encounter OOM’s, particularly if their recycling settings aren’t aggressive enough. Too aggressive recycling settings can cause problems also. Storing session state out of process is one of the simplest things you can do to avoid OOM’s and other issues associated with depletion of available virtual memory. Unfortunately, our default session state store is in process so many don’t consider moving session state out of process until they have a production issue. Storing session state out of process does have some implications (ie Serializable objects) so it’s worthwhile making this change early in your development cycle so you avoid the inconvenience of having to implement this change under the pressure associated with a production outage.
307598 INFO: ASP.NET State Management Overview
http://support.microsoft.com/kb/307598
3) Windows Server 2003 (or later)
Windows Server 2003 has a number of advantages over Windows 2000 for hosting ASP.NET applications:
a) You can isolate each web application/app domain to its own IIS6 app pool/worker process so they aren’t sharing the same per-process 2Gb virtual address space limitation.
b) You can leverage the various worker process recycling options available in 2003. Appropriate pre-emptive recycling is a great way to avoid production outages.
c) x64 version allows 4Gb of virtual address space even in 32-bit mode. Obviously, running out of virtual address space is much less likely if you have the luxury of running in 64-bit mode.
d) /3gb switch works even in the standard version.
4) .NET 2.0 (or later)
.NET 2.0 incorporates a significant number of improvements over .NET 1.x and most .NET 1.x sites will run under .NET 2.0 without modification. Note, .NET 2.0 isn’t installed by default on Windows Server 2003 so you’ll need to install it manually. If nothing else, the highly recommended threading configuration settings documented in KB 821268 are defaults in .NET 2.0.
821268 Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
http://support.microsoft.com/kb/821268
5) Increase the allowed number of outbound HTTP connections from the default (2).
By default, in order to be a compliant HTTP 1.1 client, .NET only allows 2 outbound HTTP requests per process/host. Whilst this might be appropriate if you’re building a Winforms app, it can be a bottleneck for server-side applications like ASP.NET websites that are doing web service calls, etc. You can increase the allowed number of outbound HTTP connections via the maxconnection .config setting. KB 821268 recommends 12 * N where N is the number of logical CPU’s in your ASP.NET server.
