I recently spent some time looking at why an ASP.Net web site took a long time to start up. In the case I looked at, I ended up shaving over 30 seconds off the startup time of every app pool by fixing the following issues:

·         If your app deserialises anything (and that includes web.config files) make sure you run sgen against your binaries and GAC the resulting DLLs to ensure all your serialisation objects are cached. This can save over two seconds on the first access of every XML file. Here is an article on using sgen:

http://msdn.microsoft.com/en-us/library/bk3w6240(VS.80).aspx

·         If your IIS servers do not have outgoing access to the internet, turn off Certificate Revocation List (CRL) checking for Authenticode binaries by adding generatePublisherEvidence=”false” into machine.config. If this setting is true and the web site doesn’t have outbound access to the internet (and many web sites don’t) there can be a long delay (over 20 seconds) while an attempt to retrieve the CRL list is made. Here are a couple of references on this:

http://blogs.msdn.com/amolravande/archive/2008/07/20/startup-performance-disable-the-generatepublisherevidence-property.aspx

http://msdn.microsoft.com/en-us/library/bb629393.aspx

·         If you need locks on commonly accessed resources make sure you use ReaderWriterLockSlim to protect them if your resource is read mostly. Using a standard lock on a commonly accessed, read mostly, resource (e.g. config files) can seriously impact scalability as all access to the data is serialised even if it isn’t modified. The Reader-Writer lock allows multiple concurrent access for reading and only requests an exclusive lock when the data is modified. Here is a reference on using ReaderWriterLockSlim:

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

Interestingly the one thing that I thought would save a lot of time which really didn’t help very much at all was ngen’ing the binaries. This is because unless you carefully set the base load addresses of all your binaries so that they don’t overlap at build time, they end up having to be rebased when they are loaded which almost completely counters then benefit of running ngen on them.

I had about thirty DLLs to work with, all of which were configured to load at the same default load address and I simply didn't have time to work out suitable load addresses for all of them. There was also a risk that they would change in the near future and the work would have to be carried out all over again! The potential gain didn't seem to be worth the effort and the other changes already made had  sufficient improvements without this. Here is an article on ngen and setting dll load addresses to avoid rebasing:

http://msdn.microsoft.com/en-us/magazine/cc163610.aspx