在最近对Azure Web api发生故障进行调查之后(它不喜欢冷启动,因为排队的请求然后淹没了服务器(503)),我收到以下消息:
网站绑定状态更改后,您的应用程序已重新启动。由于最近的部署插槽交换操作,很可能发生这种情况。在某些情况下,交换后,生产版位中的Web应用可能稍后会重新启动,而应用所有者不会采取任何措施。重新启动可能会在交换发生后几个小时/天发生。当Azure App Service的基础存储基础结构进行某些更改时,通常会发生这种情况。发生这种情况时,该应用程序将同时在所有VM上重新启动,这可能会导致冷启动和HTTP请求的高延迟。该事件在一天中发生了多次。
建议是
为了最大程度地减少随机冷启动,您可以在应用的每个插槽中将此应用设置WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG设置为1。
有人可以详细说明吗?我是否正确地认为,如果将来在某个随机时间进行交换(例如,过渡到生产),应用程序将重新启动?
应用程序设置实际上是做什么的,它将如何停止Azure重新启动生产插槽?
帕特里克·古德(Patrick Goode)提供的链接的答案,他的google-foo比我的好得多
“仅说明WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG应用程序设置的具体细节。默认情况下,我们将站点的主机名放入站点的applicationHost.config文件的“绑定”部分。然后,当交换发生时,applicationHost.config中的主机名将与内容不同步实际站点的主机名。运行该应用程序无论如何都不会影响该应用程序,但是一旦发生某些存储事件(例如,存储卷故障转移),该差异将导致工作进程应用程序域回收。然后设置而不是主机名,我们将站点名放入appHost.config文件的“ bindings”部分中。站点名在交换期间不会更改,因此交换后不会出现此类差异,因此不应重新启动。”
看起来此设置应该可以防止“随机冷重启”
https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句