A few years ago I blogged about a way to keep your web application running in IIS. To summarize the blog posts, IIS 7.5 introduced the Application Initialization Module that allowed you to start a worker process without waiting for a request.
To activate this feature you have to dive into the applicationhost.config file directly and change the startMode of your application pool to alwaysRunning:
<system.applicationHost>
<applicationPools>
<add name="DefaultAppPool" autoStart="true" startMode="alwaysRunning" />
</applicationPools>
</system.applicationHost>
This will guarantee that the moment your application pool is started, a worker process spins ups decreasing the time to handle the first request.
Unfortunately the blog posts wasn’t complete. Although the steps above guarantee that a worker process is spinned up immediately, it doesn’t mean that the application is loaded into the worker process.
The Application Initialization module provides a solution here by adding a new property to the application settings called preloadEnabled. We’ll have to dive into the applicationhost.config file again to set this value:
<system.applicationHost>
<sites>
<site name="Default Web Site" id="1">
<application path="/">
<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
</application>
<application name="WebApp1" applicationPool="DefaultAppPool" preloadEnabled="true">
<virtualDirectory path="/WebApp1" physicalPath="c:\inetpub\wwwroot\WebApp1" />
</application>
</site>
</sites>
</system.applicationHost>
This will guarantee that our application is always up and running.
What is happening behind the scenes?
From https://blogs.iis.net/wadeh/application-initialization-part-2:
Here's how Application Initialization uses this property. When a new worker process spins up, Application Initialization will enumerate all of the applications that it will host and checks for this property. For any application where preloadEnabled="true", it will build a URL corresponding to the default page for the application and run it through the pipeline. This request does not go through the network, and there is no client listening for a response (IIS discards any data that would have gone to the client.)
This "fake" request accomplishes a few key things. First, it goes through the IIS pipeline and kicks off an application start event. This initializes a number of parts inside of IIS, and if the request is for ASP.NET, it will cause global.asax to run. It also reaches the application, which will see it is the first request after starting.