EntityFramework.Docs VS Entity Framework 6

Each release of Entity Framework Core the Microsoft engineers provide code samples. Although these code samples are great, they are not structured for learning and use in a developer’s projects. Also, there are many code samples that may not be useful to the average developer. With that said I took Microsoft code samples and structured the code in a fashion suitable for the average developer to learn from.

This is documented well for Entity Framework Core, with code samples as well, but there isn't any clear information about having a multi-tenant, multi-db approach for the token cache. The official Multi tenant Azure AD documentation does mention the token caches, but it doesn't talk about a multi-db approach.

Even from the Microsoft example, they use .HasData in their modelbuilder. MicrosoftGithubSeedExample

What have you tried? What doesn't work? The link you provided is a fairly straightforward example of the concept. Including the sample code.

Take a look at this sample project: https://github.com/dotnet/EntityFramework.Docs/tree/main/samples/core/Miscellaneous/Testing/ItemsWebApi/Tests

Additionally, an individual context will also cache the actual sql being performed and their docs go over the caching it does here regarding that.

Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work.

https://randomascii.wordpress.com/2019/10/20/63-cores-blocke...

A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this:

https://github.com/dotnet/ef6/issues/1500

What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)