Compiling ASP.NET Applications

When an .aspx page is first requested, code is generated for a class that derives from the System.Web.UI.Page object. That derived page class is then compiled into an assembly and preserved for future requests for the same page. The code doesn’t need to be generated and compiled again, but the assembly that holds the class has a certain amount of overhead associated with it. For a single assembly, the amount of overhead is certainly not overwhelming, but an assembly for each page multiplied by hundreds or thousands of pages can lead to unnecessary drag on resources and strained performance. The cumulative effect of all that overhead can take a toll.

When the first request for a Web application is received, ASP.NET can batch compile all the pages in that directory into a single assembly, eliminating the need for multiple assemblies. The compilation element in the config files controls how the batch compilation is performed. By default, batch compilation is enabled and limits the number of pages to compile into a single assembly to 1000. These settings are fine for most Web applications as well as the batchTimeout setting that limits the batch compilation effort to 15 seconds. If the batch compilation exceeds the timeout, the attempt will be aborted to service the page request that triggered the compilation. You want to avoid losing out on batch compilation, but you also don’t want the first request to the Web application to suffer a long delay while the batch compilation occurs. The approach many sites undertake is to trigger the compilation explicitly when bringing a server or updated content online initially. This can be automated by putting together a small application that makes this initial long-running batching request automatically.

Tip

Keep batch compilation enabled, but make requests to each Web application while bringing a site online so that the first user to issue a request to the site does not see the delay of batch compilation and the whole directory can be batch compiled.

Code Listing 9-5 takes a static list of URLs, and a single page from each Web application on the local server, and requests them each in turn. This allows us to avoid showing the first user the delay of batch compilation while still enjoying the run time performance benefits.

Code Listing 9-5: TriggerBatchCompile.cs

 using System;
using System.Net;
using System.IO;
using System.Text;
 
class TriggerBatchCompile {
 
private static string[] urls = {
"http://localhost/page.aspx",
"http://localhost/anotherApplication/page.aspx",
"http://localhost/yetAnotherApplication/page.aspx"
};
 
    public static void Main(string[] args) {
        WebResponse result = null;
        for(int i = 0; i < urls.Length; i++) {
            try {
                Console.WriteLine(urls[i]);
                WebRequest request = WebRequest.Create(urls[i]);
                result = request.GetResponse();
                Stream receiveStream = result.GetResponseStream();
                StreamReader streamReader =
                    new StreamReader(receiveStream);
                char[] read = new Char[256];
                int count = streamReader.Read( read, 0, 256 );
                while (count > 0) {
                    count = streamReader.Read(read, 0, 256);
                }
            }
            catch(Exception e) {
                Console.WriteLine(e);
            } 
            finally {
                if ( result != null ) {
                    result.Close();
                }
            }
        }
    }
} 

The batch compilation has directory granularity, so pages that are updated can cause an assembly to be invalidated and cause additional compilations. But once an assembly is loaded, it can’t be unloaded until the application is unloaded. Instead, new assemblies are created for the updated content. Plan accordingly on sites with a high rate of churn. Pages that are updated frequently should be separated from relatively stable pages so that the number of recompilations is limited.