• Choose a category
• All
• Classic-Fiction

By Root 5216 0

is up and running, it notifies IIS that it is ready to receive requests. At this point, IIS shuts down the old worker process and completes the recycle in a way that doesn’t add hassle for the user.

Setting Up the Application Pool

To configure an application pool for warm-up, you need to edit the applicationHost.config file under the IIS directory. The folder is \inetsrv\config and is found under the Windows System32 folder. You need to change the value of the startMode attribute of the application pool entry from OnDemand to AlwaysRunning. Here’s the final snippet you need to have:

managedRuntimeVersion="v4.0"

startMode="AlwaysRunning" />

You can achieve the same effect in a much more comfortable way via the IIS Manager user interface, as shown in Figure 2-20.

Figure 2-20. Activating the warm-up feature for an application pool.

Because an application pool can host multiple ASP.NET applications, you also need to specify which applications the warm-up applies to. You can do that either by entering the following script into the applicationHost.config file or by using the IIS Manager interface:

...

From within IIS Manager, you just navigate to the application and select the Warm-up applet for it.

Note

Warm-up is configured at the host level, not the application level. As mentioned, changes are saved to the applicationHost.config file, not the web.config file. This means that the hoster (including a hosting company) or the administrator decides about the policy and whether or not warm-up is allowed. (In a hosting scenario, that could cause a lot of extra data to be hanging around and, subsequently, a loss of performance.)

Specifying the Warm-up Code

So far, we’ve configured the application pool for warming up, but we haven’t discussed yet the actions to take to actually warm up an application. At the IIS level, all you need to indicate is a URL to your application that runs the warm-up code.

The Warm-up applet in IIS Manager gives you a dialog box where you enter the URL to the page on your site that will execute the preloading code. You also indicate a range of acceptable HTTP status codes that indicate the success of the operation.

This approach works with both IIS 7 and IIS 7.5.

With IIS 7.5, however, you can define an autostart service provider—namely, a managed component that runs any required preloading code for a given application. Such providers are registered in the IIS configuration using the following new section:

...

There’s no visual interface to configure this aspect. You either edit the configuration file manually or resort to the generic configuration editor of IIS Manager. After you have registered a bunch of autostart providers, you can pick up one for a particular application, as shown here:

...

An autostart provider is a class designed to execute any initialization or cache-loading logic you want to run before requests are received and processed. Here’s an example:

using System.Web.Hosting;

public class MyPreloader : IProcessHostPreloadClient

{

public void Preload(String[] parameters)

{

// Perform initialization here...

}

}

When the Preload method on the autostart provider returns, IIS sets up the application to receive incoming requests. If the Preload method throws an unhandled exception, the worker process is shut down and the whole warm-up feature fails. The result is that the worker process will be activated on demand by the next Web request as in the default scenario.

However, if the preload continues to fail, at some point IIS will mark the application as broken and put it in a stopped state for awhile. (All these parameters are configurable. For more information,