Entity Framework Core - Performanzoptimierung

Session Abstract

Mit dem Entity Framework hat Microsoft vor Jahren einen Objekt-Relationalen-Mapper geschaffen, welcher sich in der .NET-Welt mittlerweile einer großen Beliebtheit erfreut. Der O/R-Mapper ermöglicht es, ohne SQL-Kenntnisse auf eine Datenbank sowohl lesend als auch schreibend zuzugreifen. Doch hier verbergen sich Risiken, denn ein O/R-Mapper erweckt den Eindruck, dass der Anwendungsentwickler sich nie wieder mit SQL zu befassen braucht - was für 80% der Abfragen in einer Anwendung auch stimmen mag. Die restlichen 20% können allerdings die gesamte Applikation durch sehr schlechte Antwortzeiten beinah unbenutzbar machen. Die unperformanten SQL-Abfragen sind jedoch nicht die einzige Quelle welche die Benutzbarkeit in Mitleidenschaft ziehen. Es spielt auch eine Rolle wie genau Entity Framework im Code verwendet wird. Nicht selten wird die Tatsache vergessen, dass die LINQ-Abfragen am Ende nicht im Arbeitsspeicher, sondern durch die Datenbank ausgeführt werden – mehr oder weniger „transparent“. In ersten Teil des Vortrags wird gezeigt auf was geachtet werden sollte, um die häufigsten Stolperfallen bei der Verwendung von Entity Framework Core zu vermeiden. Im zweiten Teil geht es darum, die generierten SQL-Abfragen zu verstehen, denn nur so kann das Problem erkannt und gelöst werden. Das wichtigste Mittel hierfür werden die Ausführungspläne sein.

Related Articles

entity framework core
Do Not Waste Performance by Not Using Temp Tables With Entity Framework Core
It has been a while since I released my article about the usage of temp tables in Entity Framework (v6). Meanwhile, Microsoft has released a completely rewritten version of its O/R mapper so my old approach is no longer applicable. But before we learn about a new one, let us…
Pawel Gerr
entity framework core
Better Entity Framework Core Performance by Reading Execution Plans
Both a LINQ query and an SQL statement are descriptions that state which data should be fetched, but not how.. Sure, when reading LINQ or SQL, we can make assumptions about the performance but not in every case. Some queries are either too fancy or too big to grasp, so our…
Pawel Gerr
entity framework core
Unnecessary Fuzzy Searches may hurt your Entity Framework Core Performance
After talking about performance issues like N+1 Queries and the Cartesian Explosion that made its comeback in Entity Framework Core 3, we will today look at a performance issue that is not tied to any Entity Framework version but is rather a general one. What do I mean by…
Pawel Gerr
entity framework core
The performance issue "Cartesian Explosion" made its comeback in Entity Framework Core 3
In Entity Framework Core 3.0/3.1 the SQL statement generation underwent significant changes. As we have seen in the previous post these changes removed both the implicit client-side evaluation and the N+1 Query Problem (which is good!). Unfortunately, these changes (re)introduced…
Pawel Gerr