Why Azure app service restarts when swapping slots?

Question

After having this issue in production for a long time, and having read anything i can find about (such as this or this or that), i made a simple test.

1. Create an empty asp.net website
2. in Application_Start, send an email or message (i've used PushBullet) to you so you know when the app starts
3. Create a new app service plan and resource group
4. Create the website on Azure and publish it
5. Create a staging deployment slot
6. Swap staging/production
7. Publish the website again so both slots have the same version of the website

So i have an empty website, no connectionstring, no slot setting :

When i click swap, I will get notifications that slots restart (at least once each).

Why is this happening ?

UPDATE:

After studying Mohit's answer, i need some more clarifications.

• We send the notification in the Application_Start method, which is triggered by the AppInit event if i understand correctly.

• I do not understand the behavior you explain. The order seems very important to ensure no downtime, yet you say it's not necessarily in that order. Why is it required to restart the app domain for the production slot ? Why would users get annoyed that the site is down (it should not) ?

• What is the "new swap" feature ? What's the difference with the "old swap" ? For my tests, i just swapped using the portal.

• You mention the "new swap" pauses before swap. I suppose it just means it waits for the applicationInitialization to complete (eg HTTP 200 on /) ?

• I've done some more testing since yesterday. In the Application_Start method, i've added some Thread.Sleep to make app startups longer. However, when i swap i see no downtime on either staging or production. Shouldn't i experience downtimes on staging, at least for the duration of my app startup ? Does this mean the slot that is warmed up then swapped with production is in fact another temporary slot that is neither staging nor prod ?

Answer 1

I have very similar problem, app is restarted after swapping to production slot and that causes unwanted downtime. After a lot of searching I found the following:

In some cases after the swap the web app in the production slot may restart later without any action taken by the app owner. This usually happens when the underlying storage infrastructure of Azure App Service undergoes some changes. When that happens the application will restart on all VMs at the same time which may result in a cold start and a high latency of the HTTP requests. While you cannot control the underlying storage events you can minimize the effect they have on your app in the production slot. Set this app setting on every slot of the app:

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: setting this to “1” will prevent web app’s worker process and app domain from recycling when the App Service’s storage infrastructure gets reconfigured.

You can find the whole Ruslany post, that I found very helpful here