Azure部署的.NET Core API首次请求响应时长过高问题咨询

1. Always On请求协议不匹配导致预热失效 #

• 如果你在App Service中开启了HTTPS Only配置，Always On发送的HTTP请求会被301/302重定向到HTTPS端点，无法正常触发应用预热逻辑，导致应用实际没有被保持活跃状态，用户首次访问仍然需要冷启动。
• 解决方案：在App Service的配置->常规设置中调整强制HTTPS跳转规则适配HTTP探活请求，也可以使用Azure可用性测试自定义HTTPS探活请求替代默认Always On功能。

2. .NET Core应用自身冷启动逻辑未优化 #

• 首次请求触发的冷启动包含运行时初始化、依赖注入容器构建、数据库连接池初始化、配置加载、中间件编译等步骤，这些操作默认只会在首次请求触发时执行，即使Always On探活成功，如果探活请求没有访问到对应的业务路径，也不会触发业务相关的初始化逻辑。
• 解决方案：
  • 在Program.cs/Startup.cs中添加预热逻辑，应用启动时主动初始化数据库连接、缓存预加载、单例服务初始化等操作
  • 配置App Service的部署槽预热功能，指定自定义预热路径，确保部署完成后所有初始化逻辑执行完成再接收流量
  • 针对.NET 6+版本，启用ReadyToRun编译选项，发布时预编译IL代码，减少运行时JIT编译耗时

3. App Service计划配置限制 #

• 如果你使用的是免费/共享层级的App Service计划，即使开启Always On也无法保证资源配额，平台会根据资源使用情况主动回收应用进程；如果是基础/标准层级，检查是否开启了自动缩放，实例扩容时新实例的首次请求同样会触发冷启动。
• 解决方案：
  • 升级到至少B1层级及以上的App Service计划，确保资源配额充足
  • 配置自动缩放的冷却时间，搭配实例预热逻辑，避免新实例直接承接用户流量
  • 开启始终就绪实例配置，预留固定数量的预热完成的实例承接流量

4. 中间件或路由配置问题 #

• 如果你的API配置了HTTPS重定向中间件、身份验证中间件等，默认的Always On探活请求默认访问根路径/会被拦截，返回非200状态码，平台会认为探活失败，无法保持应用活跃。
• 解决方案：配置单独的探活接口，跳过身份验证、HTTPS跳转等中间件逻辑，Always On请求直接访问该探活接口，确保返回200状态码。

内容的提问来源于stack exchange，提问作者Kubilay Bayraktar