When building a website, the optimal thing is that the users experience no downtime while a new version of the site is being deployed. This can however be quite complex to achieve in reality, and usually requires that you have multiple web servers.

The next best thing is that your users at least do not just get a browser showing nothing, while the page takes forever to load. While deploying, you could use the app_offline.htm, but that just blocks all requests, and when you remove it, the site still has not booted up.

In this post we will look at

• How to configure this
• What are the potential issues
• What can we do to solve it

Application Initialization

This is where Application Initialization can help you. Basically what it does, is to call a list of url’s when the site starts up. While doing so, you can have it display a static page to the user. So by making the static page just refresh itself in the browser, you can make it automagically load the actual page when it is ready. So when the site is warming up, the user will see this:

and when it is done, the actual page will show on the same url:

The configuration to do this is fairly simple. Add this to your section in the web.config

    <applicationInitialization doAppInitAfterRestart="true" skipManagedModules="false" remapManagedRequestsTo="WarmUp.html">
      <add initializationPage="/"/>
    </applicationInitialization>

Issues with the default setup

As you can see in the network tab of the browser, the warmup page is actually returning a http 200 status. That is not what we want, because we want crawlers to know that the page they are actually looking for is temporarily unavailable. So that means returning a 503 status.

Getting the right status

We are going to combine a couple of features here to get the effect we want. We will use the Url Rewrite module to return the correct status, and the to show the html page we created.

First, we create a rewrite rul that checks the {APP_WARMING_UP}. This is a variable set by the Application Initialization feature. When that is 1, we know the site is still warming up. So we return a custom response, with the 503 status.

    <rewrite>
      <rules>
        <rule name="WarmUp" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions>
            <add input="{APP_WARMING_UP}" pattern="1" />
          </conditions>
          <action type="CustomResponse" statusCode="503" statusReason="Service unavailable" statusDescription="Please try again later" />
        </rule>
      </rules>
    </rewrite>

Now, to avoid the default ugly 503 page from the IIS, we configure it to return our warmup page whenever the status code is 503.

    <httpErrors errorMode="Custom">
      <error statusCode="503" path="WarmUp.html" responseMode="File" />
    </httpErrors>

Now the network tab looks like this:

Pitfalls to be aware of

The Application Initialization will not actually serve the warmup page while the application is bootstrapping. In the case of Umbraco, this means that if you have slow code in your IApplicationEventHandler events or similar, then the user will still just be waiting to get any kind of response.

So for this approach to work, you should minimize the work done in bootstrapping, and move any heavy operation, such as warming up caches etc., to something that is lazy loaded by the requests to the site. You could for example cache you navigation on the first hit to the home page, which will be made while the user is seeing the warm up splash page.

Prerequisites

You cannot test the Application Initialization in IIS Express. You need a full IIS site, and you need to install the feature.

You also need to have the IIS Url Rewrite module installed.

Both of these should be default be available on an Azure Web App.

Umbraco is not a requirement for this, but this post was just written with Umbraco in mind. You can use this approach with any asp.net application.

Conclusion

This sums up my experience with this technique. I think it is a nice middle ground to improve the user experience during deployments or app pool recycles, without having a multi server setup.

Let me know if you found it useful 🙂