Practical ASP.NET

Preloading Your ASP.NET Applications

You may have noticed that the first request to an ASP.NET Web site takes longer than subsequent requests as worker threads are started, database connections opened and cached data loaded. One of my clients implemented a two-step process to eliminate this problem. First, they put code in a page on the site that would perform a bunch of initialization activities (primarily, load the Cache object with data). Second, they assigned some low-ranking person (often an intern) to request that page from the site. To ensure that the data is loaded before the first "real" user makes a request, the intern comes in very early in the morning to trigger the processing.

IIS 7.5 now has (in beta) an option to trigger code to run automatically whenever your Web site is started and before any requests are received -- just what my clients need. The good news is that this option works with any version of ASP.NET beginning with version 2.0. Because the feature is tied to IIS 7.5, you must be using Windows 7 or Windows Server 2008 R2 as your server.

If you want to start experimenting with the tool, first download the warmup module from and install it on your server. There are two ways to configure this option: with IIS Manager or by making changes in configuration files.

Configuring with IIS Manager
In IIS Manager, drill down to the Web site you want to autostart and double-click the Application Warm-up option in the panel in the middle of IIS manager. This will display an empty list of URLs. In the right hand "Actions" panel, click the Settings choice. That will display a settings dialog where you must check both the "Enable Application Warm-up" and the "Start Application Pool..." to enable autostart for the application pool for your Web site.

Now click on Add Request in the right-hand Actions column. In the resulting dialog, in the top textbox, enter the URL for a page on your site that will execute the preloading code. All requests return a result code so you need to indicate what result codes are acceptable in the second textbox (in most cases, you can just leave the default setting of 200-399 in place).

You can also specify parameters to pass as part of the request and whether the request is to made asynchronously (which can result in multiple startup requests being made to the site at once) or synchronously (where no request will be processed until the previous one completes). For sites that won't accept requests without a username and password (e.g. SharePoint sites), you can provide a user context.

Configuring with Config Files
You can also enable autostart with change in IIS 7.0's applicationHost.config file (you should find the file in C:\Windows\System32\inetsrv\config folder). To enable autostart for the application pool, in the applicationPools element find the <add> element for your site's application pool and add a startMode attribute, setting it to "AlwaysRunning":

<add name="PHVISSite" startMode="AlwaysRunning" />

Now, in the applicationHost.config you must add a location element pointing to your site inside the file's configuration element. Doing this enables autostart for the site itself. Inside the location element's system.webserver element, use the httpWarmupGlobalSettings element to enable Warmup for the site:

<location path="PHVISSite">
<httpWarmupGlobalSettings httpWarmupEnabled="true" />

Now that you've enabled autostart for both your application pool and your Web site, you need to specify what page to request. You do that in the application's web.config file by adding an httpWarmup element containing a requests element. Within the requests element you use add elements to specify the page to request, the acceptable result codes, whether requests are to be processed synchronously or asynchronously, and a username/password combination. Here's an example:

<add requestUrl="PHVISSite/Default.aspx"
allowedResponseCodes="200-399" warmupContext=""
sendMode="Asynchronous" />

While I've been using the term "startup", the official term is "warmup," which better describes the process when the site's application pool is recycled rather than shut down and restarted. During a recycle, the old processing threads are kept running until the threads started by this warmup signal that they're done. Only then are the old threads wound down and new requests routed to the new threads -- you get a preloaded site with no interruption of service.

And, more importantly, your intern can sleep in! Actually, since you don't need him anymore, you can just let him go.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at

comments powered by Disqus


Subscribe on YouTube