排查Azure Application Insights瀑布图中事务启动前的长延迟根因

1. 验证应用实例冷启动/预热状态 #

• 检查App Service的日志流、应用日志，搜索Application started、Hosting started关键字，对应长延迟请求的时间点，确认是否是实例启动、自动缩放后的首次请求导致冷启动延迟。
• 开启App Service的「始终开启」功能，配置预热端点，避免实例休眠或缩放后的初始化开销。

2. 排查DI服务初始化开销 #

• 控制器注入的10个DI服务中，部分服务的首次实例化（如数据库连接池初始化、配置加载、第三方资源初始化）可能导致延迟。
• 在关键服务的构造函数中添加自定义跟踪，对比长延迟与正常请求的初始化耗时：

  public class TargetService : ITargetService
  {
      private readonly TelemetryClient _telemetryClient;
  
      public TargetService(TelemetryClient telemetryClient)
      {
          _telemetryClient = telemetryClient;
          var sw = Stopwatch.StartNew();
          // 服务初始化逻辑
          sw.Stop();
          _telemetryClient.TrackTrace($"TargetService initialized in {sw.ElapsedMilliseconds}ms", SeverityLevel.Information);
      }
  }
  

• 查看Application Insights的依赖项跟踪，定位初始化耗时过长的服务。

3. 分析ASP.NET Core管道前置阶段 #

• 展开Application Insights请求跟踪的全阶段耗时，检查控制器执行前的中间件（如认证、授权、自定义中间件）是否在首次请求时存在异常耗时。
• 排查自定义中间件是否存在首次执行时加载大量数据、初始化资源的逻辑。

4. 检查应用服务资源瓶颈 #

• 查看App Service的实时指标（CPU、内存、磁盘IO），确认长延迟发生时是否存在资源耗尽导致的请求排队。
• 检查SQL Server的连接池状态，添加连接初始化跟踪，验证是否是首次请求时连接池创建导致的延迟：

  using var conn = new SqlConnection(Configuration.GetConnectionString("Default"));
  var sw = Stopwatch.StartNew();
  await conn.OpenAsync();
  sw.Stop();
  _telemetryClient.TrackTrace($"SQL connection opened in {sw.ElapsedMilliseconds}ms", SeverityLevel.Information);
  

5. 排查网络与依赖服务延迟 #

• 用App Service网络诊断工具测试到SQL Server的连通性与延迟，排除跨区域网络问题（即使同区域也可能存在首次连接开销）。
• 检查DI服务是否依赖第三方服务，验证首次请求时第三方服务的连接、响应耗时。

6. 利用性能分析工具追踪阻塞点 #

• 针对长延迟请求，查看App Service性能分析器的调用栈详情，确认线程是否处于等待锁、IO或资源的状态。
• 使用dotnet-trace捕获请求跟踪，分析线程活动定位阻塞点：

  dotnet-trace collect --process-id <目标进程ID> --providers Microsoft-DotNETCore-SampleProfiler
  

内容的提问来源于stack exchange，提问作者Chris Rockwell