如何防止azure在其他实例就绪之前将其扩展出去? [英] how to prevent azure from scaling out additional instances until they are ready?
问题描述
我们在使用Azure应用程序服务时遇到问题.我们的其中一项Web服务(MVC)在启动(Application_Start)时会缓存数据库中的数据-这大约需要3分钟.在准备就绪之前，我们无法处理请求.
这是众所周知的，因此我们将其设置为始终打开"，并且旨在仅在非高峰时间重新启动它.
但是，我们预计下个月服务器将承受沉重的负载，并且在我们对自动扩展的测试中，我们发现当它添加其他实例时，这些实例中的每个实例都会经历相同的启动延迟-但是流量在当前正在运行的实例和正在预热的新实例之间进行分配，例如在这3分钟内，一半的请求开始失败.
我们如何配置Azure以延迟使用新实例直到准备就绪? (或者我们应该使用例如AWS?).
一些文档指出使用自定义负载均衡器探针，但是它主要讨论的是VM，而我们正在使用PAAS.
请尝试减少需要在app_start上加载的数据，并尝试在首次请求时将数据延迟加载到Cache中.有时甚至在完成所有这些操作之后，我们的确会获得大量启动时必不可少的数据.
有两种方法可以解决这个问题.
一个，假设您正在使用内存中缓存，并且该应用程序的每个实例都需要在App_Start上混合其内存中缓存.尝试使用新的外部缓存提供程序，例如 Azure缓存Redis 实例可以指向该外部缓存，而不必重新加载数据.
二，您可以依赖应用程序初始化模块 IIS 7.5(安装在Azure App Services的IIS上).要使用此功能，您需要在web.config的web.server部分下添加applicationInitialization部分.这将帮助您在预热过程完成之前不使实例可用.有关如何使用ApplicationInitialization的更多信息，请参见此博客文章
最好的情况是将两者结合使用，applicationInitialization将指向您应用程序中的一个页面，该页面检查外部缓存是否可用并已合并，如果是，则完成，否则合并外部缓存. >
We are having issues with an Azure Application Service. One of our webservices (MVC) caches data from the database at startup (Application_Start) - this takes approximately 3 minutes. Until this is ready we can't handle requests.
This is known so we set it 'always on' and will aim to only restart it during off-peak times if necessary.
However, we expect heavy load to the server next month, and in our testing of the auto-scaling, we have found that when it adds additional instances, each of these instances goes through the same startup delay - but the traffic is split between the current running instance and the new one that's warming up so e.g. half of the requests start failing for that 3 minute period.
How can we configure Azure to delay using the new instance until it is ready? (or should we be using e.g. AWS instead?).
Some of the documentation points to using a custom Load Balancer Probe however it mainly talks about VM's whereas we are using PAAS.
Do try to reduce the data you need to load on app_start and try to lazy load data into Cache on first request. Some times even after doing all of this we do end up with large sets of data that is necessary on start.
There are two ways we can approach this.
One, assuming you are using in-memory caching and every instance of the app needs to hydrate its in-memory cache on App_Start. Try to use a external cache provider like Azure Cache for Redis, your new instance can just point to this external cache without having to reload the data.
Two, you can depend on Application Initialization Module which was introduced in IIS 7.5 (installed on Azure App Services' IIS). To use this feature, you need to add applicationInitialization section under web.server section of web.config. This will help you not make the instance available until the warm-up process is completed. More info on how to use ApplicationInitialization is available in this blog post
The best case would be to use the combination of both, applicationInitialization will point at a page in your application which checks if the external cache is available and hydrated, if yes, complete, else hydrate the external cache.
这篇关于如何防止azure在其他实例就绪之前将其扩展出去?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
