问实体框架6在SaaS环境/场景中的启动性能

EN

每个DB上下文在第一次被访问时都会产生一次性的启动成本，因此您需要确保客户端连接只接触它自己的DbContext，以避免第一次启动等待所有客户端DB上下文被访问。对于我的模型，我有一个通用的数据库，初始登录使用它来解析客户端应该与哪个版本的数据库对话，从那里经过身份验证的用户被移交给他们的数据库。您最不希望看到的就是以任何方式遍历DbContexts的代码。

编辑:以上内容不正确，通过测试验证。相同模式的DbContext实例命中同一应用程序域中的不同数据库实例时不会产生启动成本。web应用程序的关键因素是如何将应用程序域限定为请求的作用域。(考虑任何负载平衡等)

另一个要考虑的因素是使用DB-First，并将数据库初始化器设置为#null，以避免任何迁移检查等。这将节省启动时间。

您可以采用有界上下文来服务于您的应用程序的关键区域。上下文定义越大、越复杂，启动所需的时间就越长。通过使用有界上下文来覆盖应用程序中紧密相关的区域，您可以减少首次使用时启动给定上下文所需的时间。例如OrderManagementContext、CustomerManagementContext。实体可以在每个上下文中引用，但您可以优化定义，其中您只需要在不在顶级处理该实体的上下文中使用摘要表示。例如，当我处理订单时，我需要一个客户摘要。OrderDbContext不是映射整个Customer及其我不关心的相关实体，而是映射一个OrderCustomer实体，该实体只映射Customers表(或视图)中的字段，用于处理订单时我需要的有关某个客户的字段。每个上下文中的更少、更小、更简单的实体=更快的上下文初始化。

最后，当用户登录时，通过对上下文中的一个实体执行一个简单的查询，在登录过程中提早启动上下文。这会触发映射的初始一次性旋转，这样第一个“真正的”查询就不会因为延迟而命中。也就是说。

using (var orderContext = new OrdersDbContext())
{
   var result = orderContext.Orders.Any();
}
using (var customerContext = new CustomersDbContext())
{
   var result = customerContext.Customers.Any();
}

它们中的每一个都执行一个非常快的查询，但是初始化初始自旋命中的映射。

除了最小化您的上下文启动成本之外，您可能还需要考虑的另一个因素是您的环境正在进行的任何负载平衡以及对启动成本的可能影响。spin up与应用程序域相关联，因此负载平衡的问题是，该spin-up是否必须发生在每个worker上。(这超出了我所知道的，我会从最小化上下文旋转成本开始，然后开始偷看那个兔子洞，如果它仍然需要的话。)