Why is my Sitecore Website on Azure Staging Slot not Warming up?

When deploying in a single server environment, cold-starts and slow initial load times cannot be avoided as data needs to be fetched and caches needs to be built before the site can load up. To avoid this, many have gone with a blue/green deployment strategy in which one server is deployed to, warmup, and then swap. This allows for zero downtime deployments and no interruptions to your visitors.

When utilizing Azure PaaS (azure web apps) for your Sitecore website, it is heavily recommended to utilize staging slots for blue/green and application initialization module for warm up.

Recently, I've encountered an issue where the applicationInitialization seemly doesn't work; once the swap completes, we encounter cold-starts and slow initial load times.

Our configuration is as follows:

<system.webServer>
  <applicationInitialization >
    <add initializationPage="/" hostName="mysite.com"/>
    <add initializationPage="/page-to-warmup" hostName="mysite.com"/>
  </applicationInitialization>
</system.webServer>

Verify ApplicationInitialization is working

The first step to troubleshooting is verifying that the appInit actually calls our site. We will have to enable failed request tracing in azure as this is not logged on the Sitecore logs. 

On the web.config, enable tracing. Note that we add one of our warm up paths and that the failureDefinitions includes 200 to capture all requests.

<system.webServer>
  <tracing>
    <traceFailedRequests>
      <clear/>
      <add path="/page-to-warmup">
        <traceAreas>
          <add provider="ASP" verbosity="Verbose" />
          <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
          <add provider="ISAPI Extension" verbosity="Verbose" />
          <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,Rewrite,iisnode" verbosity="Verbose" />
        </traceAreas>
        <failureDefinitions statusCodes="200-600" />
      </add>
    </traceFailedRequests>
  </tracing>
</system.webServer>

In kudu, you can find your logs in c:\home\logfiles\w3svcxxxxx.

As an aside, the application initialization module only supports http so if you have https rewrite, we have to add a rule to NOT redirect for requests made by the module. 

The module's user agent is IIS Application Initialization Warmup.

Adding a no redirect rule on web.config

<rewrite>
  <rules>
    <rule name="No redirect on warmup request (initialization user agent)" stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTP_USER_AGENT}" pattern="Initialization" />
      </conditions>
      <action type="Rewrite" url="{URL}" />
     </rule>
    <rule name="Root Hit Force HTTPS Redirection" enabled="true" stopProcessing="true">
      <match url="^$" ignoreCase="false" />
      <conditions>
        <add input="{HTTPS}" pattern="^OFF$" />
        <add input="{HTTP_METHOD}" pattern="GET" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite> 

I initially had thought that the issue was that since our site is https and that since the warmup only supports http that the issue was that we were getting response code 301, but we were getting 200 responses in the log. You can view the log by clicking download next to the file in Kudu.

Configure ApplicationInitialization to Warmup Staging slot

Looking at the requested URL, I soon realized that the module was actually hitting the live slot as set by the hostName attribute! The solution is to remove that attribute so that the request will be made to whichever slot is brought up (staging slot for swaps and live slot when scaling the application).

<system.webServer>
  <applicationInitialization >
    <add initializationPage="/" />
    <add initializationPage="/page-to-warmup" />
  </applicationInitialization>
</system.webServer>

By removing the hostName attribute, the module will make a request to localhost. This also means we need to configure your Sitecore site to also respond to localhost, otherwise your pages will not be properly served by Sitecore.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <sites>
      <site name="website" hostName="localhost|mysite.com" ... />
    </sites>
  </sitecore>
</configuration> 

I also recommend putting the the warmup ping path and the warm up ping statuses on your application's configuration settings. The warm up ping statuses is especially important as by default all response codes are valid.

WEBSITE_SWAP_WARMUP_PING_PATH: /
WEBSITE_SWAP_WARMUP_PING_STATUSES: 200,301,302 

Once the above changes have been set, our site was properly warmed up.