Почему Container.Configure занимает так много времени?

Question

Сегодня я исследовал медлительность в нашей системе. Добавляя некоторые журналы отладки, я сузил его к этому сегменту:

var db = MyDbContext.ForShard(shardKey); 
_logger.Debug("Point 1"); 
container.Configure(cfg => 
        { 
         _logger.Debug("Anon 1"); 
         cfg.For<MyDbContext>().Use(db); 
         _logger.Debug("Anon 2"); 
        }); 
_logger.Debug("Point 2"); 

баз данных является sharded и shardKey определяет, какой осколок использовать. Вызов MyDbContext.ForShard() возвращает соединение с базой данных, строка подключения которого относится к правильному осколку. Затем рассматриваемый фрагмент сообщает StructureMap Container использовать этот экземпляр для инъекции зависимостей.

В журналах временной лаг между каждой линией ничтожно мал, за исключением разрыва между «Anon 2» и «Point 2», который может занимать область секунды. Нехорошо. Но я никогда не видел, чтобы StructureMap так долго настраивал использование.

Я делаю что-то неправильно здесь?

Answer 1

Как ответил хороших людей от StructureMap на их GitHub странице:

@CoreyKaylor говорит: вызов конфигурации не должно произойти во время выполнения, только при запуске, так что если этот вызов происходит для каждого веб-запроса как пример был бы чрезвычайно медленным, так как для вызова configure требуется глобальная блокировка. Лучшей альтернативой, если вам абсолютно необходимо переопределить время выполнения, является использование вложенного контейнера для области HTTP-запроса и передача TypeArguments во вложенный контейнер. Это все предполагается, что вы используете последнюю версию StructureMap.

В моем случае это приводит к:

var db = MyDbContext.ForShard(shardKey); 
var typeArgs = new TypeArguments(); 
typeArgs[typeof(MyDbContext)] = db; 
var nested = container.GetNestedContainer(typeArgs);