Amazing Bad Performance after converting ObjectContext to DbContext

After I changed from ObjectContext to DbContext (database first) in a very big app, my server was going crazy about Garbage Collector, performance was a mess and lots of not reachable, timeout, and all flavors of nasty errors appeared.

After reading a lots, and profiled the server, found out that 50% of processor time was on Find method, so I removed the use of Find for a GetById which actually calls find but turns AutoDetectChanges to false then true. This was the first tweak that actually improves substantially the performance.

After that I profiled and see two methods being heavy used. both are Get of large collections (imagine a GetProduct with lots of relations)

Went down to those methods and did the same, (AutoDetectChanges to false while getting the data).

Those method are read only, so I guess it's safe to turn off AutoDetectChanges.

Before, with ObjectContext the application run smoothly. Thing is, our code is very like :

var someEntityDTO = service.GetSomeEntityDTO(...) // Get a DTO
service.SomeLogic(someEntityDTO) // Perform some logic, update, whatever.

CreateUpdate method on DTO does map all properties from DTO to Entity, save changes and return Entity.

signature would be similar to this :

public SomeEntity CreateUpdate(){
    var someEntity = context.FindById(Id);
    if (someEntity == null)
       var someEntity = context.SomeEntities.Create();
    someEntity.Name = Name;
    someEntity.OtherProperty = OtherProperty
    someEntity.OtherEntityCollection = OtherEntityCollectionDTO.CreateUpdate();
    // .... BIG ETC (including relations and lot of nasty stuff :D

When loading collections, it's like this :

var entitiesDTOs = service.GetSomeEntityList();

the code inside the pseudo GetSomeEntityList is like this :

var ret = context.SomeEntities.Where( .... )
return ret.Select(x => new SomeEntityDTO(x));

and the constructor of the DTO is like :

public SomeEntityDTO(SomeEntity entity) {
     Id = entity.Id;
     Name = entity.Name;
     OtherEntityDTO = new OtherEntityDTO(entity.OtherEntity);
     AnotherEntitiesDTO = entity.AnotherEntities.Select(x=> new AnotherEntityDTO(x)); 
     // ... ETC with more properties and Navigation.

As I understand, those mapping are BAD for EF 6 DbContext when tracking lots of objects.

Another point of interest is that DbContext is created for each web request and passed along all methods called.

So instead of the above code of geting a collection of DTOs, the real code is more like :

entity.AnotherEntities.Select(x=> new AnotherEntityDTO(context, x)); 

While I could improve the performance a lot with the tweaks, I'm looking for some suggestion, considerations, help or comments about why my application went from smooth to chaotic and how can I improve the code practices to reach the 'smooth' point again.

I tryied to simplify most of the code (it's not real code) just for brevity/clarity. If you need more info don't hesitate to ask.

Arquitecture simplified is : MVC(n) --> WCF --> BLL --> DAL(DbContext) | Entities(POCO) Multiple MVC applications, consume a main WCF service which call a DLL containing the business logic and dbcontext is on another layer (DAL). Entities are POCO classes in a separate project.


Need Your Help

Java - JButton text disappears if actionPerformed defined afterwards

java swing text action jbutton

This has been bugging me for a while. If I define setText on a JButton before defining setAction, the text disappears:

How to handle situation with IAP internet loss

ios networking in-app-purchase

I have one button in my app, which is supposed to show the price of item, then if you tap on it you can buy an item. Initially that button is disabled and has no price on it. After application is

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.