Creating instance of Entity Framework Context slows down under load

Here is where I would start to solving the problem, sans moving to a more enterprise friendly solution.

Our context is a fairly large code-first context with around 300 entities 

While EF has greatly improved over time, I still would start seriously looking at chopping things up once you get to 100 entities (actually I would start well before that, but that seems to be a magic number many people have stated - concensus?). Think of it as designing for "contexts", but use the word "domain" instead? That way you can sell your execs that you are applying "domain driven design" to fix the application? Maybe you are designing for future "microservices", then you use two buzz words in a single paragraph. ;-)

I am not a huge fan of EF in the Enterprise space, so I tend to avoid it for high scale or high performance applications. Your mileage may vary. For SMB, it is probably perfectly fine. I do run into clients that use it, however.

I am not sure the following ideas are completely up to date, but they are some other things I would consider, based on experience.

• Pre-gen your views. They are the most expensive part of the query. This will help even more with large models.
• Move your model to a separate assembly. Not so much a perf thing than a pet peeve of mine in code organization.
• Examine your application, model, for caching possibilities. Query plan caching can often shave quite a bit of time off.
• Use CompileQuery.
• When feasible, use NoTracking. This is a huge savings, if you do not need the feature.

It looks like you are already running some type of profiler on the application, so I am going to assume you also looked at your SQL queries and possible performance gains. Yes, I know that is not the problem you are looking to solve, but it is something that can contribute to the entire issue from the user perspective.

In response to @WiktorZichia's comment about not answering the question about the performance problem, the best way to get rid of these types of problems in an Enterprise System is to get rid of Entity Framework. There are trade offs in every decision. EF is a great abstraction and speeds up development. But it comes with some unnecessary overhead that can hurt systems at scale. Now, technically, I still did not answer the "how do I solve this problem they way I am trying to solve it" question, so this might still be seen as a fail.