Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the performance benefit of pooling DbContexts #10125

Closed
dotnetjunkie opened this issue Oct 20, 2017 · 16 comments

Comments

Projects
None yet
9 participants
@dotnetjunkie
Copy link

commented Oct 20, 2017

Since EF Core 2.0 it supports pooling of DbContext instances. I can find statements from @anpete such as:

The new method introduces a few limitations on what can be done in the OnConfiguring() method of the DbContext but it can be adopted by many ASP.NET Core applications to obtain a performance boost.

Implying that pooling give a performance boost, while @ajcvickers states:

The point of DbContext pooling is to allow reuse of DbContext instances from a pool, which for certain scenarios can result in a performance boost over creating a new instance each time. This is also the primary reason for connection pooling in ADO.NET, although the performance boost for connections will be more since connections are generally a more heavyweight resource.

Implying that DbContext pooling is not as significant as connection pooling.

I couldn't find any analysis or benchmarks of the actual performance improvement this brings. To my knowledge, the creation of DbContext instances is really light. A small local test showed that I could make over 600,000 instances a second on a single thread.

I found this question from @davidroth:

Out of curiosity: Can you share some benchmarks about this improvement?

Unfortunately, the question was ignored.

What does cause a performance hit when DbContext instances are not reused? Can we find a publically accessible benchmark that shows what the benefit of pooling is and especially an alalysis of what is causing the bottleneck without the reuse of DbContext instances?

Thanks in advance.

@ErikEJ

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2017

You can see it in action in the demo: https://github.com/anpete/EFDemos

@dotnetjunkie

This comment has been minimized.

Copy link
Author

commented Oct 20, 2017

Great, thay does show a runnanle example with the performance difference, but it still lacks an analysis of why this difference exists. Why is calling a property on a DbContext so much slower the forst time? What is happening under the covers?

@ErikEJ

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2017

The Model is built/configured and cached in the AppDomain, I think.

@popcatalin81

This comment has been minimized.

Copy link

commented Oct 20, 2017

@dotnetjunkie Very good question, after the first instantiation when the metadata model is created DbContext instances should be very cheap in practice. Even if dependency injection is use to create supporting services.

The only explanation is that DbContexts don't share internal services and for each context a large graph of supporting services needs to be instantiated.

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Oct 20, 2017

@dotnetjunkie DbContext initialization is a two-part process. Creating the instance itself does minimal work--basically just initializing any DbSet properties. This means creating a DbContext that is not used does not add significant overhead, which is important for scenarios such as a controller that may need to access the database but often does not--just injecting/creating the instance should not be a perf issue.

The first time the context is used, for a query, to track something, etc., there is a second lazy initialization that happens. This involves loading some services from EF's internal D.I. that are scoped to the same lifetime as the context. Not all services are like this--many are singletons that are shared between all context instances. Also, not all services are initialized at this time--services that may not be needed can be loaded lazily--however, we have seen that this is sometimes more expensive than loading immediately due to the way the D.I. system compiles constructor calls.

The second initialization step is also not really slow, but DbContext pooling means that instead of doing this step, an existing pooled instance is used instead, with resetting of the service internals. This is less flexible--each context instance in the pool must be configured the same way so that the same set of services with the same configuration is correct each time.

Whether or not this really shows a measurable difference in your app depends a lot on how much else the context is doing. Where it works well is for simple, no-tracking queries where very little other work is being done. As soon as the context starts to do more work, the relative amount of time saved by pooling is much less.

It's also worth keeping in mind that there is additional initialization which is not bound to a particular context instance. So, for example, the first time a model is used by any context instance there will be a hit while the model is built and cached. Likewise for the first time a query is executed, and so on. Pooling will not have any impact on these things.

Hope that helps!

@anpete

This comment has been minimized.

Copy link

commented Oct 20, 2017

Apart from what @ajcvickers said, an additional benefit of pooling is that it can drastically reduce allocations. This can greatly benefit high-scale scenarios such as loaded web servers etc. - we saw a ~30% throughput improvement on some of TechEmpower benchmarks. As always, measure for your application and then decide.

@gius

This comment has been minimized.

Copy link

commented Sep 14, 2018

What if there are unsaved modifications on tracked entities after a DbContext is used? Will it be saved when the instance is reused from the pool and called SaveChanges? Can/should I dispose of a DbContext when using pooling?

Won't the long-lived DbContext get slower and slower as it will track more and more entities over all reuses? Or is the tracker reset when the DbContext is returned to the pool?

@smitpatel

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2018

@gius - All services including ChangeTracker are reset when the DbContext is returned to the pool. So whenever you get a context from pool, it is same as what it would be if you re-initialize it (except for few limitations).

@simeyla

This comment has been minimized.

Copy link

commented Jan 29, 2019

@smitpatel Can this be done manually on a normal context? ChangeTracker.Reset() ? I can't seem to find anything like that.

@zanate4019

This comment has been minimized.

Copy link

commented Mar 7, 2019

@smitpatel Can this be done manually on a normal context? ChangeTracker.Reset() ? I can't seem to find anything like that.

I'm not sure how the EF team is resetting, but I think detaching all tracked entities is the equivalent of resetting the ChangeTracker.

approximate-code:
var entries = context.ChangeTracker.Entries().ToList();
entries.forEach( e => e.State = EntityState.Detached);

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@zanate4019 Detaching all entities is quite slow. Creating a new context instance would be much faster.

@zanate4019

This comment has been minimized.

Copy link

commented Mar 7, 2019

Thanks again for your timely input Arthur. Good to know.

So back to @smitpatel 's question. Is there a way for us to manually reset the ChangeTracker? I am thinking about how to manage the memory footprint of a long-lived context. Resetting the change tracker could be a decent alternative to disabling it altogether.

Jason

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@zanate4019 Best practice is to not use a long-lived context. Instead, use a new context instance for each unit-of-work. Is there a reason you are using a long-lived context instance?

@zanate4019

This comment has been minimized.

Copy link

commented Mar 8, 2019

I understand that short-lived contexts are best.

We have real-time workflow system with a mixture of WPF and Winforms clients with a WCF pub-sub back-end that pushes updates. We are moving to a unified ASP.NET core / Angular 7 frontend where notifications are pushed through signalr and initial data loads are handled through a REST API.

In this instance, this windows service I am building is just needed in the transition. It will pickup updates once a second from the system database and send them out to clients through signalr. We expect to only need it 6 months. Since it only runs 4 selects and 4 corresponding group of updates once a second to pickup the updates and then mark them notified I had planned to use the same implementation of our repository interface and just let core inject the context at startup.

I guess I could create a special repository implementation that gets a transient context from the service provider rather than have it injected in the constructor. Current version I just turned off change tracking.

I'm still curious about the best way reset ChangeTracker.

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@zanate4019 Thanks for the additional info. It certainly sounds to me like a short-lived context instance--i.e. a new one each second to pick up and send updates--is the way to go here.

To answer you question directly, the best way to "reset the ChangeTracker" is to create a new context instance. (Yes, pooling does some internal stuff to reset the context, but it has limitations and works in the context (no pun intended) of pooling.)

@zanate4019

This comment has been minimized.

Copy link

commented Mar 9, 2019

Ok -- new repository it is. Not a problem -- only need to actually implement the 8 methods the service needs.

Thanks again for your help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.