我们遇到Azure应用服务的问题。我们的一个Web服务（MVC）在启动时缓存数据库中的数据（Application_Start） - 这大约需要3分钟。在此之前，我们无法处理请求。
这是众所周知的，因此我们将其设置为“始终打开”，并且只在必要时才会在非高峰时段重新启动它。
但是，我们预计下个月服务器负载很重，而且在我们测试自动扩展时，我们发现当它添加额外的实例时，每个实例都会经历相同的启动延迟 - 但流量是在当前运行的实例和正在升温的新实例之间分配，例如一半的请求在3分钟内开始失败。
我们如何配置Azure以延迟使用新实例，直到它准备好？ （或者我们应该使用例如AWS吗？）。
有些文档指出使用自定义Load Balancer Probe但是它主要讨论VM而我们正在使用PAAS。
答案 0 :(得分：1)
请尝试减少需要在app_start上加载的数据，并尝试在首次请求时将数据延迟加载到Cache中。有时甚至在完成所有这些操作之后，我们最终还是获得了启动时必需的大量数据。
有两种方法可以解决这个问题。
一个，假设您正在使用内存中缓存，并且该应用程序的每个实例都需要在App_Start上充填其内存中缓存。尝试使用Azure Cache for Redis之类的外部缓存提供程序，您的新实例可以指向该外部缓存，而不必重新加载数据。
两个，您可以依赖IIS 7.5（安装在Azure App Services的IIS上）引入的Application Initialization Module。要使用此功能，您需要在web.config的applicationInitialization部分下添加web.server部分。这将帮助您在预热过程完成之前不使实例可用。 this blog post
最好的情况是将两者结合使用，applicationInitialization会指向应用程序中的一个页面，该页面检查外部缓存是否可用并已合并，如果是，则完成，否则合并外部缓存。
答案 1 :(得分：0)
您可以在Azure中使用经典VM（例如App Service）以外的其他资源类型来执行此操作。 App Services可以使用共享相同内存池和线程池的实例来进行扩展和缩减。
答案 2 :(得分：0)
其中一条评论中包含的链接https://www.jan-v.nl/post/warming-up-your-app-service中有很多很好的信息。
基于该信息，免费套餐中没有您需要的功能。
我会以不同的方式处理这个问题。为什么要花3分钟从数据库中加载数据？由于它仅在启动时加载，因此应该是不经常更改的数据。
可以吗？
答案 3 :(得分：-1)
我的建议是将Azure负载均衡器与运行状况探针一起使用