为什么创建新的DbContext比依赖项注入慢?

问题描述

通过在.NET Core中使用依赖注入的DbContext和使用异步等待调用(而不是每次我想访问数据库时都创建新的DbContext)，都不会显着提高性能.

I recently determined that there are no significant performance gains from using a Dependency Injected DbContext in .NET Core and using async await calls as opposed to creating a new DbContext every time I want to access the DB.

但是现在我需要知道为什么.

But now I need to know why.

我在.NET Core 1.1 API服务(控制器正在调用)中对System.Diagnostics.Stopwatch进行了更细化的测试，仅在访问数据库时才运行秒表.结果令人惊讶.

I did a much more granular test with System.Diagnostics.Stopwatch in my .NET Core 1.1 API services (which the controller is calling) in which I ran the stopwatch only when accessing the DB. The results were surprising.

在使用标准的依赖注入上下文和异步/等待调用时:

When using the standard Dependency Injected context and async/await calls:

var task1 = _InjectedDbContext.Table1.FirstOrDefaultAsync(p => p.Id == SomeId);
var task2 = _InjectedDbContext.Table2.Where(u => u.AnotherId == SomeOtherId).ToListAsync();

(var result1, var result2) = await (task1, task2).WhenAll();

每个DbContext查询花费的时间明显少于100毫秒.

each DbContext query took significantly less than 100 ms.

但是，使用此方法时:

using (var context = new DbContext(_InjectedContextOptions.Options))
{
    var task1 = context.Table1.FirstOrDefaultAsync(p => p.Id == SomeId);
    var task2 = context.Table2.Where(u => u.AnotherId == SomeOtherId).ToListAsync();

    (var result1, var result2) = await (task1, task2).WhenAll();
}

每个DbContext查询耗时100-230毫秒.

Each DbContext query took anywhere from 100-230 ms.

仅供参考，这是我在Startup.cs ConfigureServices中进行DI设置的代码:

FYI, here is my code for the DI setup in Startup.cs ConfigureServices:

var connection = Configuration.GetConnectionString("mydb");
services.AddDbContext<MyDbContext>(options => options.UseSqlServer(connection));

这是我的代码，每当我创建新的DbContext时，就以单例形式提供DbContextOptions:

And here is my code for providing the DbContextOptions as a singleton whenever I create a new DbContext:

var dbContextOptions = new DbContextOptionsBuilder<MyDbContext>();
dbContextOptions.UseSqlServer(Configuration.GetConnectionString("MyDb"));
services.AddSingleton(dbContextOptions);

我还确定，延迟不是由using语句中创建DbContext引起的(这是一个非常快速的操作).这里发生了什么?是不是每次都尝试重新连接到数据库?

I also determined that the lag is not caused by simply the creation of the DbContext in the using statement (which is a very fast operation). What is going on here? Is it trying to re-connect to the DB every time or something?

推荐答案

对于第一种情况下使用的DbContext，您正在使用AddDbContext方法，该方法将DbContext作为作用域添加到服务中(如果我没有记错的话)).由于优化，添加服务后可能会立即初始化DbContext(此处不确定).对于第二种情况，您将创建一个新的DbContext.除了创建DbContext之外，还需要完成其他一些工作.

You're using the AddDbContext method, for the DbContext you use in the first scenario, which adds the DbContext to services as Scoped (if I'm not mistaking). The DbContext is probably initialized as soon as the service is added because of optimization (not sure here). For the second case you're creating a new DbContext. Apart from the DbContext creation there's also some other stuff that needs to be done.

来自这篇文章，这里有一些热身"您的环境的提示:

Taken from this post, here are some tips to 'warm-up' your context:

1. 使用缓存的数据库模型存储
2. 生成预编译视图
3. 使用n-gen生成entityframework的预编译版本，以免出现抖动

以上提示表明，使用DbContext不仅可以更新" DbContext并开始查询.

The tips above indicate there's more to using a DbContext than 'just' newing one and start querying.

这篇关于为什么创建新的DbContext比依赖项注入慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！