10
votes

About a year ago, Azure Web App slot swaps were "seamless" - once it was complete, the new instance was warmed up to accept new requests without any delay.

Now, when I swap slots from STAGING to PRODUCTION, even after running tests against STAGING to warm up the app, swapping results in many moments of warm-up time.

How may this have changed, and what can I do to ensure that my app remains 100% accessible during a swap?

3

3 Answers

4
votes

Have you made any changes to your slot configs?

There are a few things that I've noticed will contribute to the swap not being immediate after warmup on production, and they kind of make sense if you think about it:

  • In each slot config under "Application Settings", if the app settings or connection strings are not exactly the same for any settings that have the 'slot config' checkbox is UNchecked, then in those cases it will do the warm-up, then the swap, then has to warm up again because it seems to update those settings after the swap (so it seems).
    • To be sure your settings are correct, if you're doing a manual swap, check that the azure portal says "no warnings" to ensure the system doesn't have to do anything out of the ordinary
  • On a manual swap, the source and destination choices matter. This is because the source slot is first warmed up with the destinations slot config (so it will be slow during warmup) then the swap happens, which means the source becomes the destination, which should be immediate. Then the warmup happens again to get the original source back to it's original settings. So if you choose the wrong item for your source, the warmup time will be DOUBLE.
  • Make sure you have the applicationInitialization setting in your web.config to force the warmup to hit a url on your site before the swap:

    <system.webserver> <applicationInitialization> <add initializationPage="/" /> </applicationInitialization> </system.webServer>

1
votes
1
votes

How may this have changed, and what can I do to ensure that my app remains 100% accessible during a swap?

As far as I know, normally warn up actions should complete in the staging slot before swapping it into production. This eliminates downtime when we deploy web app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. this blog that Ruslan wrote explained the sequence of actions that happens when a staging slot is swapped into production, you could read it. And as Garrett said, if it does not completely warm up, custom warm-up actions could be helpful.