Entity Framework 18 seconds on first call to SaveChanges ()

I have a very large Entity Framework implementation (100+ tables / entities). The first time SaveChanges is called while doing an update, I get a timeout of 18 seconds. Is this generally accepted for wireframe LOB models? I've heard that splitting the EF model into smaller chunks is a way to improve performance. I am wondering if this is the only way? Separation seems like a lot of work at this point.

  • Do I have to split the EF model?
  • Should I use multiple instances of the data context, or just a generic static one?
  • What is the performance you experienced with the slowness on EF and in particular SaveChanges ()?

Thank!

+2


source to share


3 answers


I see the same problem in my project. The first call to SaveChanges takes about 12 seconds and full CPU time, while the next calls do not.

The first polling of objects took about the same amount of time before I used pregenerated Views. Now the 12 second first poll delay has not gone through, but the first call to SaveChanges still takes a long time. Maybe there is a way to create the code for SaveChanges beforehand ...



[Edit] I just wanted to mention that I managed to get rid of the first save delay by changing the database structure. The entity that is taking so long to save is a large table with a lot of foreign key constraints on another table (don't ask). Eliminating foreign key constraints did the trick. [/ Edit]

+1


source


No, this is not expected behavior. Our entity model is the same as yours and we don't see it. You need to profile your application to figure out what the problem really is before you go away trying to fix it. I cannot offer you a solution without knowing what your profiling results are.



0


source


The place where we store most of the data in EF in one operation is a few hundred lines spread across ca. 80 tables. This has a second response time.

It must be related to something else to check:

  • Are you using any processor during those 18 seconds? What process?
  • Could this be a network timeout issue?
  • Is it related to the constructor compiler or jit?
0


source







All Articles