-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Performance regressions on EF scenarios #36292
Comments
Should we transfer this to the runtime repo? |
@Pilchie that's probably where it should be. There is a chance that it gets closed since it's not regressing from the previous version. It's an unfortunate "local" regression. But I am sure some investigation will definitely be done to at least understand the reasons. |
I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label. |
@sebastienros didn't you say it was from @adamsitnik 's change (single epoll thread?). We have diffs to show what changes affect the graph right? |
EF looks like it went up for a day or two and then went back down to what it was. Were the few measurements showing a temporary increase legit? Just making sure. Also, what is the magnitude of the regression? It's hard to tell from the screenshot, but it looks fairly small? |
Here are the actual runtime versions that regressed, and links to commits. I can't be more precise than that as it's based on the available runtime builds. Scenario: DbFortunesEF
Command line:
Pinned ASP.NET version across runs. |
Tagging subscribers to this area: @dotnet/ncl |
Moving to sockets area, since this is related to epoll changes. |
Triage: worth an investigation. @antonfirsov @adamsitnik can you help here? |
From the numbers provided here, it looks like #35330 has improved the performance compared to 3.1 and #35800 has brought it back to the previous level (for these particular benchmarks). The goal of the first PR was to allow us to switch to a single epoll thread (second PR), which gave us BIG wins in all platform benchmarks. I would say that it was an unplanned improvement which was simply reverted by the other PR that gave us very important wins elsewhere. @sebastienros Do we have a I am going to set it to the future for now (it does not look like a regression compared to previous release) |
I think pushing this out is fine. That said, while the issue is still fresh in our minds, any ideas what might have caused this @adamsitnik? |
@sebastienros thanks for the link, it was exactly what I needed! I've run the benchmarks for 3.1.5 vs 5.0 using perf machine (12 cores, close to real life scenarios) and Citrine (TechEmpower, 28 cores):
there are improvements for ADO.NET and one regression for EF for a machine with a high number of cores
@geoffkizer If ADO.NET did not improve, I would say that we can't keep the ThreadPool busy with a single epoll thread. But since only EF has regressed for a machine with a high number of cores I guess that something which was not a bottleneck so far, became a bottleneck (lock contention?). We need to run a full investigation to find out (and hopefully change something in EF). |
triage: this was open for 5.0 and all the linked issues are closed. Not clear if this is really actionable. We should investigate perf improvements separately. |
Most probably due to threadpool/epoll changes on the same commit.
dotnet/aspnetcore#21593
dotnet/aspnetcore#21596
dotnet/aspnetcore#21634
dotnet/aspnetcore#21640
dotnet/aspnetcore#21650
dotnet/aspnetcore#21688
The lines that are up are either ADO.NET or Dapper. The ones that are down are EF.
/cc @adamsitnik @roji
The text was updated successfully, but these errors were encountered: