Application Initialization

What is Application Initialization in IIS?

It is a very useful module in IIS that allows us to warm up the application before it receives requests. This helps us avoid our application receiving requests before it is ready to process them, and issues related to the time it takes to load our application after a restart.

What should we consider before implementing this module?

• If your initialization page performs any immediate redirection
• If your application requires HTTPS

These are the most common issues we may face when using the Application Initialization module. It is important to note that this IIS module is only available for HTTP requests. Therefore, if your application has a redirection to HTTPS (following best practices to force users to make connections to your application through the HTTPS protocol), it is possible that this module will not behave as expected.

How does the Application Initialization module work?

This module sends a request to a specific page, which should have already been configured in your application’s configuration file, the web.config.

When this request is made, it only expects a response, which can be of any type. By this, I mean that regardless of the response code returned by this request, IIS believes that the application is ready to handle the request and its initialization is complete, so it will start sending requests to the process.

Therefore, if your application returns a 4xx,5xx, or 3xx status code, it will still be considered ready to process requests. For example, if you have a redirection rule that returns a 302 status code, IIS will consider that your application is ready to receive requests when it is not the case.

In scenarios where you scale out your service plan horizontally, these issues of requests arriving before the application is ready to process them should rarely occur because the App Service has two distinct roles, the “FrontEnd” and the “Worker,” in the infrastructure. The “Frontend” should not send requests to the “Workers” until they are ready to start processing requests.

How to troubleshoot issues with Application Initialization

The only way to track whether the initialization is being performed correctly is by enabling failed request logs. You can do this from the Azure portal.

Add the following section in bold to your web.config. In the <Add Path> section, add the configured initialization page for this module. This will allow us to reduce the amount of logs created by FREB and capture any status code returned by the request.

<?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <system.web>
        </system.web>
        <system.webServer>
            <applicationInitialization >
                <add initializationPage="/customwarmup.php"/>
            </applicationInitialization>
            <tracing>
                <traceFailedRequests>
                    <clear/>
                  <add path="/customwarmup.php">
                    <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>
</configuration>

How do I obtain the log files?

1. Go to Kudu

2. Go to D:/home/Logfiles/W3SVCxxxx

   NOTE: To access Kudu, you can do so through the portal. In your application, go to Advanced tools or access it directly through <yourapplicationname>.scm.azurewebsites.net

3. Click on the Download icon, and now that we have the logs, we need to search for the request that has the path of your initialization process, in our case, it would be customwarmup.php.

If the request was made via the HTTP protocol, it is highly likely that the response to your request will be a 200 status code. This indicates that the warming module worked correctly.

However, if you force the request to use the HTTPS protocol, the response will be a 301 redirection. In this case, the initialization page would not have warmed up my application correctly.