Programming Microsoft ASP.NET 4 - Dino Esposito [21]
As you’ll see in much more detail in Chapter 4, a managed HTTP module is a class that implements a specific interface—the IHttpModule interface. In its startup code, the HTTP module programmatically registers as the handler for one or more of the request events. Next, you register the module with the application and just wait for it to kick in for each and every application request.
Note that the HTTP module can be registered in two ways: via the configuration file of the application (web.config) or administratively through the IIS Manager tool. Mappings set directly within IIS Manager are stored in the applicationHost.config file.
In IIS Manager, you select the Modules applet and then bring up the dialog box shown in Figure 2-6 to add a new module by specifying its unique name and, of course, the type.
Figure 2-6. Adding a new HTTP module in IIS Manager.
An HTTP module can operate on both ASP.NET managed and native requests. A native request is intended as a request that doesn’t strictly require the ASP.NET runtime machinery to be served successfully. The canonical example of a native request is a JPEG image or a static HTML page.
Some New Features in IIS 7.5
Recently, IIS 7 has been further refined to better serve the needs of Web developers and site administrators. Here’s a quick list of new features you might want to take advantage of to improve the performance and effectiveness of ASP.NET applications.
Note that the list is not exhaustive and is mostly meant to serve the needs of members of an ASP.NET development team rather than site administrators. For example, IIS 7.5 incorporates a number of administrator-level extensions that have been released along the way as add-ons to IIS 7, such as the Application Request Routing and the URL Rewrite Module. The former is a routing module that forwards HTTP requests to content servers based on predefined settings to ensure proper balancing of traffic. The latter is a highly configurable module to block, redirect, and rewrite incoming requests.
For developers, features like application warm-up and hardened security are perhaps more attractive.
Autostarting Web Applications
It comes as no surprise that some Web applications might take a while to get up and running and ready to serve the first request. Application restarts happen for a number of reasons, and sometimes they’re beyond the explicit control of the site administrators. (I’ll get back to application restarts in a moment.)
If the application needs to perform expensive initialization tasks before serving the first request, every restart is a performance hit. The user all of a sudden experiences significant delays and can’t easily figure out why. There are no fancy ways to solve the issue; in the end, all you need to do is keep your application awake and “distribute” the time it takes to initialize your application across its entire uptime. This might mean, for example, that if your application requires lengthy database processing, you ensure that data is cached in a location that’s faster to access than the database itself. Some effective solutions in this regard have been arranged using an always running Windows service. All the service does is periodically refresh a cache of data for the Web application to access from within the Application_Start event handler in global.asax.
ASP.NET 4 and IIS 7.5 on Windows Server 2008 R2 offer an integrated solution to this relatively frequent issue. A new feature named autostart provides a controlled approach for starting up an application pool and initializing the ASP.NET application before the application can accept HTTP requests.
You edit the configuration file of IIS to inform IIS of your intentions and then provide your own component that performs the warm up and accomplishes whatever tasks are required for your application to be as responsive as expected. The feature is a joint venture between IIS 7.5 and ASP.NET 4. ASP.NET ensures the preloader component is invoked