Application Initialization for Sitecore on PaaS. Hot swapping made easy!

In this blog post, I will explain how the Application Initialization module works and why it is essential for Sitecore production environments during scaling operations and slot swapping without downtime (known as hot swapping). Furthermore, I will show you how to enable the application initialization module in your solution step by step keeping your web.config neat.

This blog is for all Sitecore Solutions running on Azure PaaS and especially very beneficial for apps that:

  • Scale horizontally(in/out) multiple times per day
  • Swap slots during high load

Generally, you want zero downtime deployment for new versions of your application. There have been times that you want to deploy a new release to your production environment during peak hours or that the current amount of servers is not enough to handle the load and your webApps need to scale out in order to handle the incoming requests. In times like these, you want your scaling and swap operations to leave the user experience intact, and in order to achieve this, you need to prepare (warmup) your environment before it starts receiving requests.

What is it and how it works

What is it? The AppInit(Application Initialization) module is an IIS feature to help you warm up a website before it starts receiving actual requests from users.

How the application Initialization module actually works? The only thing you need to do is specify a list of endpoints in your web.config that you want to “hit” in order to warmup your website. When a website is starting up, the module starts pinging all the endpoints (one by one) in the configuration in the specified order and waits for a response from the server. The module does not require a successful response to proceed in the next endpoint, so any response (even a 500!) is sufficient to go on. It might be a good idea to create some custom endpoints in your application for a better warmup One thing to note is that the AppInit(Application Initialization) module cooperates with the internal load balancer and along with the LOCAL_CACHE setting. When local cache is enabled, the swap operation waits for the local cache to be filled and the AppInit module to finish. For common issues with slot swapping check out this blog.

Application Initialization during swap operations

How the AppInit modules works during a swap operation between a staging and a production slot:


Figure 1a: A swap operation is initiated(STAGING -> PRD) after successfully deploying and testing the new release to the staging slot.


Figure 1b: The production settings are applied in the staging slot, which causes the restart of the staging slot instances.


Figure 1c: The AppInit module kicks in and starts warming up the instances, by doing a request to each one of the endpoints defined in the configuration file.


Figure 1d: The AppInit module finishes and the instances are warmed up. The load balancer gets notified.


Figure 1e: The swap operation finishes and the users are redirected to the “new” production environment. The previously production slot(left) now gets the settings of the staging slot. This causes a restart and the instances are in a cold state. The AppInit module will start on the staging slot instances as well until all the endpoints are hit and the staging slot is also warmed up.

Application Initialization during scaling operations

How the AppInit module works during a scale-out operation:


Figure 2a: A scale-out operation is initiated because of extra load on the time being (scale-out by two instances).


Figure 2b: The two new instances come in the instance pool. The load balancer knows that the AppInit module is not finished on those instances yet and thus, the two new instances do not receive any requests yet.


Figure 2c: The AppInit module start hitting the endpoints defined in the configuration file in order to warmup the new instances.


Figure 2d: The AppInit module hit all the endpoints in one of the instances and now this instance is considered warmed up and ready to receive requests. The load balancer gets notified and starts sending requests to this instance as well.


Figure 2e: Same as figure 2d, for the second new instance.


Figure 2f: All the new instances are warmed up and are receiving requests from the load balancer.

Note: There is no actual “New Instances” instance pool. The new instances are joining the same instance pool and the load balancer decides if they are receiving any requests or not. The two boxes(left: PRD, right: New instances) is only for illustration purposes.

Setting up the configuration files

To keep the web.config clean, we will create a file that contains all the endpoints that we want to be hit by the AppInit(Application Initialization) module and then, inside the web.config we will add a reference to this file. To achieve this you can follow the steps below.

  1. First create the applicationInitialization configuration and place it in its own file inside App_Config folder.

The name of the file is: “Mirabeau.ApplicationInitialization.config”

<?xml version="1.0"?>
<applicationInitialization doAppInitAfterRestart="true" skipManagedModules="true" remapManagedRequestsTo="SplashPage.html">
    <!--This initialization in essential for autoscaling/swapping.
    List the pages that need to be warmed up before traffic is allowed in the webapp.  NOTE:No duplicate entries allowed-->

    <add initializationPage="/page/under/different/host/" hostName="myhost"/>
    <add initializationPage="/popular/page1/" />
    <add initializationPage="/popular/page2" />
    <add initializationPage="/popular/page3/" />
    <add initializationPage="/popular/page4/" />

    <add initializationPage="/warmup.aspx" />
  • The <doAppInitAfterRestart> is an optional Boolean attribute: Specifies that the initialization process is initiated automatically whenever an application restart occurs. The default value is false.
  • The <skipManagedModules> is an optional Boolean attribute. Specifies whether the managed modules are loaded (false) or not loaded (true) during initialization. The default value is false.
  • The <remapManagedRequestsTo> is an optional String attribute. Specifies a page to remap a request to during application initialization.

For more information on this topic, you can visit the following Microsoft docucment.

To achieve the best warmup of your application, you should add as many endpoints as possible in this file. The more the merrier, but be aware that as your “Mirabeau.ApplicationInitialization.config” grows in endpoints, the slower your scale/swap process will be. This is not a bad at all, it means that your application will be in a good state to receive requests from the users, so do not worry about it.😀

The last endpoint (“warmup.aspx” in the example above) can be used to write a file in the logs, indicating that the current instance is warmed up (example: warmup.Timestamp.txt). This comes handy when you want to make sure that the new instance is ready or you want to find out how long does the warmup takes.

  1. In the web.config, add a custom <sectionGroup> inside the <configSections>:
    <sectionGroup name="applicationInitialization" 
        type="CustomConfig.applicationInitialization" >
    <section name="add" type="applicationInitialization.PageInit.CorePagesToWarmUp"/>
  1. Add the applicationInitialization node in the web.config under <system.webServer>
<applicationInitialization configSource="App_Config\Mirabeau.ApplicationInitialization.config"/>

*If your website requires SSL, then the AppInit module will not work out of the box. Check out this post from MS on how to setup a URL rewrite rule to workaround this limitation of the module.


Read all our Sitecore blogs here.