Delays or latency in the construction of controllers for every request in .net core

Question

We use microservice architecture with .net core 6 for one service that gets configs from other api instead of appsettings.json file. The problem is the existing latency for every request or handling event from rabbitmq. We also saw these logs:

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)

that there was more than a second delay in creating a controller. This is where there is a possibility of latency (my repository class constructor):

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;
        }

There were no errors in the logs. Because we had also used Redis and there was a possibility of thread theft in the library used to connect to it, also used the following config to set the minimum number of threads, but the problem still remained: ThreadPool.SetMinThreads(100, 100);

We searched and tried a lot to solve this problem.

Answer 1

IOptionsSnapshot<Dictionary<string, BrandsConfigurations>> brandsConfigurations,

Because using the above item results in the following:

Options are computed once per request when accessed and cached for the lifetime of the request.

If there are many configs that you receive through the api when starting the app, and in multiple constructors used by IOptionsSnapshot, there will be a lot of delay due to the computing for each item.

If you use IOptions instead of IOptionsSnapshot, no more computing and processing will be done and no delay will be created for each request.

You have to manually update the config if needed.

for more info use this link