本文介绍了为什么在交换插槽时 Azure 应用服务会重新启动?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在生产中遇到此问题很长时间后,并阅读了我能找到的任何内容(例如

当我点击交换时,我会收到插槽重启的通知(每个至少一次).

为什么会这样?

更新:

在研究了 Mohit 的回答后,我需要进一步澄清.

  • 我们在 Application_Start 方法中发送通知,如果我理解正确,该方法由 AppInit 事件触发.

  • 我不明白你解释的行为.该顺序似乎对于确保没有停机非常重要,但您说它不一定是该顺序.为什么需要重新启动生产槽的应用程序域?为什么用户会因为网站关闭而烦恼(它不应该)?

  • 什么是新交换"功能?与旧交换"有什么区别?对于我的测试,我只是使用门户交换.

  • 您在交换之前提到了新交换"暂停.我想这只是意味着它等待 applicationInitialization 完成(例如/上的 HTTP 200)?

  • 从昨天开始我又做了一些测试.在 Application_Start 方法中,我添加了一些 Thread.Sleep 以使应用程序启动时间更长.但是,当我交换时,我发现暂存或生产都没有停机时间.我不应该在登台时遇到停机时间,至少在我的应用程序启动期间是这样吗?这是否意味着预热然后与生产交换的插槽实际上是另一个既不是 staging 也不是 prod 的临时插槽?

解决方案

我有非常相似的问题,应用程序在切换到生产槽后重新启动,导致不必要的停机.经过大量搜索,我发现了以下内容:

在某些情况下,在交换后,生产槽中的 Web 应用程序可能稍后会重新启动,而应用程序所有者无需采取任何操作.这通常发生在 Azure 应用服务的底层存储基础结构发生一些变化时.发生这种情况时,应用程序将同时在所有 VM 上重新启动,这可能会导致冷启动和 HTTP 请求的高延迟.虽然您无法控制底层存储事件,但您可以将它们对生产槽中的应用程序的影响降至最低.在应用的每个插槽上设置此应用设置:

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG:将此设置为1"将阻止 Web 应用的工作进程和应用域在应用服务的存储基础架构重新配置时回收.

你可以找到整个 Ruslany 帖子,我觉得这很有帮助 这里

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 ?

解决方案

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

这篇关于为什么在交换插槽时 Azure 应用服务会重新启动?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-12 22:21