Ребята, перевёл проект asp.net core 2.2 на dotnet 5.0. Сразу

столкнулся со снижением производительности всех API запросов в несколько раз! Подозрения падают на Dependency Injection. Используется встроенный IServiceCollection + AutoFac для расширенного функционала. Ниже три наблюдения:

1. Есть два разных класса DbContext. При инициализации обоих используются самописные DbConnectionOptionsReader, возвращающие connection string. Но для одного этот класс зареган как AddSingleton и простой запрос на этом DbContext (контекст.таблица.Count()) занимает 0.02 сек. На другом зареган как AddScoped и там такой же запрос занимает .25 сек - в 12 раз дольше! Если для эксперимента сделать второй тоже AddSingleton - то они начинают выполняться одинаково быстро

2. Создал новый dotnet 5.0 проект, скопипастил в него всё основное из первого проекта, чисто чтобы запустить тот же пример. Так вот пример отрабатывает одинаково быстро на обоих DbContext, независимо от того как зереганы их поставщики connection string - Singleton или Scoped. Это наводит на мысль, что скорость замедляют куча регистраций классов бизнес-логики в основном проекте. Или что-то другое.

3. После перевода на dotnet 5 проект иногда стал падать с ошибкой:

Autofac.Core.DependencyResolutionException: An exception was thrown while invoking the constructor 'Void .ctor(Microsoft.EntityFrameworkCore.DbContextOptions`1[EsDb.DbContextRo])' on type 'DbContextRo'.
---> System.InvalidOperationException: An error was generated for warning 'Microsoft.EntityFrameworkCore.Infrastructure.ManyServiceProvidersCreatedWarning': More than twenty 'IServiceProvider' instances have been created for internal use by Entity Framework. This is commonly caused by injection of a new singleton service instance into every DbContext instance. For example, calling 'UseLoggerFactory' passing in a new instance each time--see https://go.microsoft.com/fwlink/?linkid=869049 for more details. This may lead to performance issues, consider reviewing calls on 'DbContextOptionsBuilder' that may require new service providers to be built. This exception can be suppressed or logged by passing event ID 'CoreEventId.ManyServiceProvidersCreatedWarning' to the 'ConfigureWarnings' method in 'DbContext.OnConfiguring' or 'AddDbContext'.

Что опять же намекает на проблему с DI, но я не понимаю причины этой ошибки. Написано, что это может быть вызвано из-за этого что мы используем Singleton'ы при создании DbContext, Но ведь, насколько я знаю, Singleton как раз и следует использовать, в этом случае экземпляр создаётся один раз на запрос, что повышает производительность, нежели чем создавать экземпляр один раз AddScoped или AddTransient. Или это намёк что вообще ничего не стоит инжектить в DbContext?

а энтити фреймворк где зареган? внутри автофака или мс ди?

DbContext зареган на IServiceCollection ServiceCollection.AddDbContext(вызов_функции_резолвящей_DbConnectionOptionsReader) ServiceCollection.AddDbContextFactory(вызов_функции_резолвящей_DbConnectionOptionsReader) DbConnectionOptionsReader тоже зареган на IServiceCollection

А перекинь его на автофак и попробуй; такое ощущение, что автофак где-то лишнее создает, судя по сообщению из ошибки

попробовал зарегать в автофак (убрав регистрацию из IServiceColleciton) - никак не поменяло время выполнения

контекст ты как синглетон регаешь ?

инстанс на скоуп

А что профайлер говорит?

попробуй выпилить AutoFac

у нас весомая логика связана на его ILifetimeScope и ParentScope, малой кровью не отделаешься, так что это вариант лишь на перспективу

ну оно же заменяемо через ms диай

Проблемы очевидно в DI скоупах, думаю автофак обходит дефолтную валидацию и начинается цирк с зависимостями от неправильных лайфтаймов. Два варианта есть: выпилить автофак; выпилить инъекцию DbContext, заменить ее на фабрику, надеюсь она не используется как UnitOfWork. Быстрого решения проблемы нет.