blocks|key|2792155|text|每个DB上下文在第一次被访问时都会产生一次性的启动成本，因此您需要确保客户端连接只接触它自己的DbContext，以避免第一次启动等待所有客户端DB上下文被访问。对于我的模型，我有一个通用的数据库，初始登录使用它来解析客户端应该与哪个版本的数据库对话，从那里经过身份验证的用户被移交给他们的数据库。您最不希望看到的就是以任何方式遍历DbContexts的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2792156|编辑:以上内容不正确，通过测试验证。相同模式的DbContext实例命中同一应用程序域中的不同数据库实例时不会产生启动成本。web应用程序的关键因素是如何将应用程序域限定为请求的作用域。(考虑任何负载平衡等)|2792157|另一个要考虑的因素是使用DB-First，并将数据库初始化器设置为#null，以避免任何迁移检查等。这将节省启动时间。|2792158|您可以采用有界上下文来服务于您的应用程序的关键区域。上下文定义越大、越复杂，启动所需的时间就越长。通过使用有界上下文来覆盖应用程序中紧密相关的区域，您可以减少首次使用时启动给定上下文所需的时间。例如OrderManagementContext、CustomerManagementContext。实体可以在每个上下文中引用，但您可以优化定义，其中您只需要在不在顶级处理该实体的上下文中使用摘要表示。例如，当我处理订单时，我需要一个客户摘要。OrderDbContext不是映射整个Customer及其我不关心的相关实体，而是映射一个OrderCustomer实体，该实体只映射Customers表(或视图)中的字段，用于处理订单时我需要的有关某个客户的字段。每个上下文中的更少、更小、更简单的实体=更快的上下文初始化。|2792159|最后，当用户登录时，通过对上下文中的一个实体执行一个简单的查询，在登录过程中提早启动上下文。这会触发映射的初始一次性旋转，这样第一个“真正的”查询就不会因为延迟而命中。也就是说。|2792160|using+(var+orderContext+=+new+OrdersDbContext())
{
+++var+result+=+orderContext.Orders.Any();
}
using+(var+customerContext+=+new+CustomersDbContext())
{
+++var+result+=+customerContext.Customers.Any();
}|code-block|syntax|javascript|2792161|它们中的每一个都执行一个非常快的查询，但是初始化初始自旋命中的映射。|2792162|除了最小化您的上下文启动成本之外，您可能还需要考虑的另一个因素是您的环境正在进行的任何负载平衡以及对启动成本的可能影响。spin+up与应用程序域相关联，因此负载平衡的问题是，该spin-up是否必须发生在每个worker上。(这超出了我所知道的，我会从最小化上下文旋转成本开始，然后开始偷看那个兔子洞，如果它仍然需要的话。)|2792163|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Each DB Context will incur a one-off spin-up cost when it is first accessed, so you will want to ensure that a client connection is only touching its own DbContext to avoid that first spin-up waiting on all client DB Context's being touched. For my model I have a common database that the initial login uses to resolve what versioned database a client should be talking to, from there the authenticated user is handed off to their database. The last thing you want is code that iterates over DbContexts in any way.

Edit: The above is not correct, verified with a test. DbContext instances for the same schema hitting different database instances in the same application domain do not incur the spin-up cost. The key factor for a web application is how the application domain is scoped to the request. (considering any load balancing, etc.) 

Another factor to consider is to use DB-First and setting the database initializer to #null to avoid any Migrations checks etc. This will save spin-up time.

You can adopt bounded contexts to service key areas of your application(s). The larger and more complex a context definition is, the longer the spin-up takes. By using bounded contexts to cover closely related areas of an application you can cut down on the time needed to spin up a given context on first use. For instance OrderManagementContext, CustomerManagementContext. Entities can be referenced in each context, but you can optimize the definitions where you only need a summary representation in a context that doesn't treat that entity at a top-level. For instance when I'm working with orders, I need a summary of customer. Rather than mapping the whole of Customer and it's related entities that I don't care about, the OrderDbContext maps a OrderCustomer entity which only maps the fields from the Customers table (or view) for the fields I need about a customer when dealing with orders. Fewer, smaller, simpler entities in each context = faster context init.

Lastly, when a user goes to log in, spin up the context(s) early as part of the login process by executing a simple query against one entity in the context. This triggers the initial one-off spin up for the mapping and that way the first "real" query won't get hit with that delay.
I.e. 

<pre><code>using (var orderContext = new OrdersDbContext())
{
 var result = orderContext.Orders.Any();
}
using (var customerContext = new CustomersDbContext())
{
 var result = customerContext.Customers.Any();
}
</code></pre>

Each of these executes a very fast query, but initialize the mapping for that initial spin-up hit.

Another factor you may to consider beyond minimizing your contexts spin-up cost is any load balancing your environment is doing and possible implications for spin-up costs. The spin up is associated to an application domain, so the questions there will be with load balancing whether that spin-up has to happen on each worker or not. (That's beyond what I know, I'd start with minimizing the context spin up cost, then start peeking down that rabbit hole if it's still needed.)

We use EF6.2 in our Web SaaS application. We have database per account architecture which means every customer gets separate SQL Server database.

What we see is extremely slow startups. We also see startups getting proportionaly slower with amount of accounts we add.

We currently do not use any of optimizations possible. We don't do ngen, we don't "pre-compile" views. But what bothers me is that it's not performance hit we take overall, but per account.

That leads me to beleive it is related to metadata cache which according to article here being built in-memory and tagged with hash derived from connection string. 
<a href="https://docs.microsoft.com/en-us/ef/ef6/fundamentals/performance/perf-whitepaper" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/ef/ef6/fundamentals/performance/perf-whitepaper</a>

<blockquote>
 3.4.1 Metadata Caching algorithm
 
 1.Metadata information for a model is stored in an ItemCollection for each EntityConnection. •As a side note, there are different
 ItemCollection objects for different parts of the model. For example,
 StoreItemCollections contains the information about the database
 model; ObjectItemCollection contains information about the data model;
 EdmItemCollection contains information about the conceptual model.
 
 2.If two connections use the same connection string, they will share the same ItemCollection instance.
</blockquote>

Looking for any suggestions on how to reduce "warm up" time to single occurence

EDIT: This is Model-first EDMX based DB, no migrations

Entity Framework 6 startup performance in SaaS environment/scenario

身份验证

数据缓存

SQL Server

数据库

SaaS

我们在Web SaaS应用程序中使用EF6.2。我们的数据库按帐户体系结构，这意味着每个客户都可以获得单独的SQL Server数据库。我们看到的是非常缓慢的初创公司。我们还看到，随着我们添加账号的数量，初创公司的会按比例变慢。我们目前没有使用任何可能的优化。我们不做ngen，我们不“预编译”视图。但让我困扰的是，我们...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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