.NET Core 6微服务请求/事件处理控制器构建延迟问题求助

我们基于.NET Core 6构建微服务，服务不从appsettings.json读取配置，而是从外部API获取。当前遇到的问题是处理请求或RabbitMQ事件时存在明显延迟，从日志可见控制器创建耗时超过1秒：

11 Feb 2023 17:41:50.406
 Executed controller factory for controller Basket.API.Controllers.MonitoringController (Basket.API)
11 Feb 2023 17:41:49.305
 Executing controller factory for controller Basket.API.Controllers.MonitoringController (Basket.API)

我们怀疑延迟出现在RedisBasketRepository的构造函数中，代码如下：

public RedisBasketRepository(ILoggerFactory loggerFactory,
           IOptions<BasketSettings> settings,
           IConnectionMultiplexer redis,
           IOptionsSnapshot<Dictionary<string, BrandsConfigurations>> brandsConfigurations,
           IInternalAPICallerService internalAPICallerService,
           IHttpClientFactory clientFactory)
{
    _logger = loggerFactory.CreateLogger<RedisBasketRepository>();
    _redis = redis;
    _database = redis.GetDatabase();
    _settings = settings?.Value ?? throw new ArgumentNullException(nameof(settings));
    _brandsConfigurations = brandsConfigurations.Value;
    _internalAPICallerService = internalAPICallerService;
    _clientFactory = clientFactory;
}

日志中无错误信息，考虑到Redis可能存在线程窃取问题，已配置ThreadPool.SetMinThreads(100, 100);，但问题仍未解决，需进一步排查。

具体排查步骤 #

1. 精准定位构造函数内的耗时操作 #

给RedisBasketRepository构造函数的关键步骤添加计时日志，明确哪个环节拖慢了初始化：

public RedisBasketRepository(ILoggerFactory loggerFactory, ...)
{
    var stopwatch = Stopwatch.StartNew();
    _logger = loggerFactory.CreateLogger<RedisBasketRepository>();
    _logger.LogInformation("Created logger: {ElapsedMs}ms", stopwatch.ElapsedMilliseconds);
    
    stopwatch.Restart();
    _redis = redis;
    _database = redis.GetDatabase();
    _logger.LogInformation("Got Redis database: {ElapsedMs}ms", stopwatch.ElapsedMilliseconds);
    
    stopwatch.Restart();
    _settings = settings?.Value ?? throw new ArgumentNullException(nameof(settings));
    _logger.LogInformation("Loaded BasketSettings: {ElapsedMs}ms", stopwatch.ElapsedMilliseconds);
    
    stopwatch.Restart();
    _brandsConfigurations = brandsConfigurations.Value;
    _logger.LogInformation("Loaded BrandsConfigurations: {ElapsedMs}ms", stopwatch.ElapsedMilliseconds);
    
    stopwatch.Restart();
    _internalAPICallerService = internalAPICallerService;
    _clientFactory = clientFactory;
    _logger.LogInformation("Assigned remaining dependencies: {ElapsedMs}ms", stopwatch.ElapsedMilliseconds);
}

重点关注IOptionsSnapshot<Dictionary<string, BrandsConfigurations>>.Value的获取——IOptionsSnapshot会在每次请求时重新加载配置，而你们的配置来自外部API，这极可能是同步阻塞的源头。

2. 修复配置加载的同步阻塞问题 #

如果BrandsConfigurations的配置是通过外部API同步获取的，会导致每次请求创建依赖时都阻塞等待API响应：

• 自定义配置提供器时，将配置加载改为异步实现，避免在Get/Load方法中同步调用API；
• 改用IOptionsMonitor替代IOptionsSnapshot，它会缓存配置并自动刷新，减少重复加载的开销。

3. 验证Redis连接的注册方式 #

IConnectionMultiplexer必须注册为单例，否则每次请求都会重新建立Redis连接，造成巨大延迟。检查Program.cs/Startup.cs中的注册代码：

services.AddSingleton<IConnectionMultiplexer>(sp => 
{
    var configuration = ConfigurationOptions.Parse("your-redis-connection-string");
    return ConnectionMultiplexer.Connect(configuration);
});

同时检查Redis连接字符串是否配置了合理的超时时间，以及服务与Redis实例之间的网络是否存在延迟。

4. 排查其他依赖的初始化开销 #

• 确认IInternalAPICallerService的注册生命周期：如果是Scoped且其构造函数包含耗时操作，会直接影响控制器创建；
• 检查IInternalAPICallerService是否在构造函数中同步发起HTTP请求，这种操作会阻塞线程，必须改为异步调用。

5. 诊断线程池状态 #

虽然已设置ThreadPool.SetMinThreads(100,100)，仍需验证线程池是否真的充足：
在构造函数中添加日志输出可用线程数：

ThreadPool.GetAvailableThreads(out var workerThreads, out var completionPortThreads);
_logger.LogInformation("Available worker threads: {Worker}, IO threads: {IO}", workerThreads, completionPortThreads);

同时检查是否存在同步上下文阻塞（比如调用Task.Wait()/Task.Result），这种操作会锁住线程，导致请求排队。

内容的提问来源于stack exchange，提问作者Hamed Lohi