As everyone with ASP.Net knows.... when the server's IIS restarts, ASP.Net needs to recompile the website and restart the application.
Restarting the application I can cope with.... as that only adds about 500ms to the initial response time
But recompilation can takes fricking ages (sometimes as much as 60 seconds)
I was wondering if anyone knew any ways to keep ASP.Net applications recompiled or the best way to get IIS to recompile applications after it restarts (I understand there's some trick I could use with Global.asa (not asax) to call all the other applications to recompile)
Without ASP.NET V2 which has a precompile option, your best bet is something like this
If you use a lot of user controls, you might be able to leverage this idea to speed your compile time?
Couple that with this to automate the process
Or just wait for V2...
I guess you could move stuff into the GAC. Perhaps you can create controls (webcontrols) and assemblies with most of the code and move them there.
Also putting code into assemblies (.dll) and moving them to the /bin folder should speed up your web app first compilation a lot.
I already use codebehind compiled classes and upload the *.dll
But whenever you first access an ASP.Net application it always does some extra compilation, and its this that drives me el loco.
Its just IIS recompiling the ASPX pages themselves, rather than any "real" code:
All my pages inherit from a codebehind and have the usual page directive:
And so on....
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="ErrorPage.aspx.vb" Inherits="Namespace.Pages.CurrentPageClass"%>
<%@ Register TagPrefix="yaf" Tagname="footer" src="controls/page/Footer.ascx" %>
<%@ Register TagPrefix="yaf" Tagname="navbar" src="controls/page/Navbar.ascx" %>
<%@ Register TagPrefix="yaf" Tagname="header" src="controls/page/Header.ascx" %>
<%@ Register TagPrefix="yaf" Tagname="sidebar" src="controls/page/Sidebar.ascx" %>
<%@ Register TagPrefix="yaf" Tagname="masthead" src="controls/page/Masthead.ascx"
%><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus IFrame 1.0//EN" "http://Dim8200/Yafas/xhtml-11-iframe.dtd">
As I recall from memory the aspx, ascx and asmx files are compiled per directory on first use.
In your case if you have all your files in the same folder all those files gets compiled.
(but I see you have a folder for controls...)
Do you happen to have some/a lot of aspx files in your root folder? Maybe the above rule should read 'on first use and all files in the root folder'.
Concluding: You might try scattering your files over more folders (and perhaps move them out of the root folder).
You're right. At Tim Sneath's blog I found the following:
The first time you browse to an updated ASP.NET website, there's always a couple of seconds pause whilst the ASP.NET worker process does something. But why should there be a wait when you've just built the web application into an assembly using VS.NET? The reason is quite surprising: ASP.NET applications using the code-behind model actually comprise two separate assemblies at runtime. Rather than interpreting the .aspx page, ASP.NET creates a class that dynamically spits out the HTML content when instantiated. This class inherits from the class created in code-behind view, so that both are linked together. The pause when you first browse to the site is caused by this class being generated, compiled and instantiated. On subsequent visits to this page, the class is already compiled (and probably also JITted), so the only step left is to instantiate it. That's why repeated visits to a page are so much faster than the initial visit. (In production this is rarely a problem, since web sites are of course long lived and used by many users.) If you want to see the class that's automatically generated, you can visit a directory called Temporary ASP.NET Files (on my machine stored at
\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files). Buried in here, you'll see an XML file for each page in the site, which contains the name of the automatically generated C# or VB class that implements the dynamic HTML rendering. As with tip #2, this location is deliberately obfuscated to prevent casual tampering, but it's worth looking here just to see what's going on under the covers.