Warm up web application during DXP Service deployments

When you deploy through the DXP Service Management Portal, warmup is configured (when needed) and tested automatically as a part of the deployment. Because it is usually the most time-consuming part of a deployment, this topic provides more detail about how you can improve the speed of warm up.

How is warm up configured for sites in DXP Service?

During the first part of the deployment, where DXP Service copies code and applies transformations, the deployment engine checks whether an Application Initialization section exists in web.config; if it does not, it is automatically created. See Warm up sites. Because of the way Application Initialization works on the underlying web server, DXP Service applies some further configuration related to rewrite rules and redirects, if needed, to ensure that the warm up requests are effective.

DXP Service accepts a redirect response in the same way as an application initialization's 200 OK response (and not "followed"), which means that a simple HTTP to HTTPS redirect could render the whole application initialization configuration almost useless. Therefore, DXP Service configures rewrite rules so that the application initialization requests are excluded from any redirects.

After the "code copy" part of the deployment has finished, the warmup process begins.

What happens during the warm up step?

1. DXP Service temporarily disables autoscaling before warmup starts. This makes the current number of instances of the web app "fixed" to avoid scaleouts that could be triggered by the warmup process.
2. DXP Service initiates the first part of a Azure web app "swap with preview." This ensures that the deployment slot created during the deployment process can receive production traffic after the swap is completed and avoid any restarts of the web app.
3. DXP Service starts the application initialization process within each individual web application instance. The deployment engine performs a couple of checks to try to validate that this process works as expected. Each individual instance's local cache status is verified to ensure the best possible performance and stability of the web app when it is swapped.
4. DXP Service analyzes the application initialization section to find a suitable hostname to poll the web app and its instances in the slot and check its response (whenever possible; a feature called routing rules uses a "real" hostname to reach the deployment slot). Some of the things analyzed in the response are:
   • If the header "X-AppInit-WarmingUp" is returned, the Application Initialization engine is still running.
   • After determining which web app instance sent the response, if the response does not come from the same instance as the request was sent to, it indicates that the load balancer in Azure has redirected the request because the Application Initialization engine is still running.
   • If the request times out, or if the instance responds with errors, it could potentially indicate that the Application Initialization engine is still running and the process keeps polling the site until the response changes or if a timeout value is met.
     When all instances of the web app are validated (or if the timeout value is met), the deployment re-enables autoscaling and lets the site get swapped after a manual validation.

How can you speed this up?

Keep local cache small

Keep the web app file size as small as possible in local cache. Otherwise, the cache is an internal process in Azure that could potentially be affected by network congestion in the underlying infrastructure.

Local cache can sometimes take only a few seconds to be ready, but it could also take several minutes. There is no guarantee that cache will be ready on all instances at the same time, which is why the deployment engine checks them individually.

Use automatic application initialization

The amount of time the application initialization process takes is highly dependent on the site and how quickly it starts. It is also affected by the number of links that are added to the Application Initialization section, especially if each page takes a significant time to load (because it is run sequentially).

You should not manually configure a minimal Application Initialization section to save time during deployment because that could cause new instances to be slow in production instead. However, it could be a balance between scaling out faster or making sure that every single page on the web app is warmed up. The logic used to create this section automatically during deployments was tried and tested over thousands of deployments and has the primary goal of making sure that scale-outs and potential restarts of instances are seamless, so you should not manually create this section.

However, making sure that the site in the slot can respond with 200 OK could save several minutes because it lets the deployment engine detect whether the application initialization process has finished (the "X-AppInit-WarmingUp" header is only returned on successful responses) instead of letting it try to validate this until it hits the timeout.

Timeout values are as follows:

• Up to 10 minutes if no warmup is detected (for example, if the site just keeps responding with errors).
• Up to 25 minutes if warmup is detected for at least one instance.

Why does this have to finish before I can swap the site?

As part of the swap process, Azure also tries to validate the slot before the swap is made. These checks include things like warmup and local cache to ensure that the new slot will behave as it should after the swap. If these checks fail, it blocks the swap request so there is no real point in trying until the site is ready.

What took so much time in my latest deployment?

The details of the warm-up process for each individual instance are logged in the detailed deployment log, which can be accessed by opening the deployment's output log and then clicking Get Detailed Log (see "Deployment job log output).