I have an ASP.NET 2.0 application (installed on IIS 6.0 from an MSI) which was compiled as a ‘web site’, and precompiled/packaged using a web deployment project, in Visual Studio 2005. (I have put in a request to the developers to consider changing to a web application for the next version, but it won’t change for this version).
Whenever the application is recycled (e.g. a change is made to the web.config), on first hit, ASP.NET JITs the application. As part of this, it takes all the assemblies required for the login page and compiles them into native code in the Temporary ASP.NET Files ‘assembly\dl3’ directory, which takes between 20 and 60 seconds. This only happens on a recycle, which happens infrequently — but when it does, it causes the page to take much longer to load, and I believe it may be possible to optimize this.
There appear to be 122 DLLs that it needs to consider, some of which are the precompiled code-behind, others are third party components for the web site (for example, NHibernate.dll, reporting components, etc.)
Why does it recompile/re-JIT everything? Why does it not detect that most of the assemblies have not changed, and not attempt to change them? Can I prove it’s not batch compilation that is causing the problem? (I have <compilation debug='false'> set in the web.config.)
Other questions suggest NGEN might be useful but I read it’s not possible to use it on ASP.NET 1.x; we are using 2.0 and I can’t find a clean answer either way.
From my personal experience slow recycle is often caused by NHibernate/ActiveRecord if you have lots of entities. See http://nhibernate.info/blog/2009/03/13/an-improvement-on-sessionfactory-initialization.html for explanation + possible solution.