Laden...

Linq-Query mit EF6 braucht sehr lange im Vergleich zum äquivalenten SqlQuery

Erstellt von padde77 vor 6 Jahren Letzter Beitrag vor 6 Jahren 3.271 Views
P
padde77 Themenstarter:in
50 Beiträge seit 2011
vor 6 Jahren
Linq-Query mit EF6 braucht sehr lange im Vergleich zum äquivalenten SqlQuery

verwendetes Datenbanksystem: MSSQL

Hi,

ich verstehe es nicht.
Wenn ich meine Abfrage im DBContext ausführe:

var id = _abfrage.Stammdaten.FirstOrDefault(p => p.CardID == CardID).ID;

braucht die Anwendung ca. 2,5 Sek. bei ca. 10 Spalten und 10 Einträgen in der DB
Wenn ich die Query in der DB laufen lasse:


SELECT TOP(1)
    [Extent1].[ID] AS [ID]
    FROM [dbo].[Stammdatens] AS [Extent1]
	WHERE [Extent1].[CardID] = 522

bin ich bei 0,15 Sek.

Meine Klasse


   public class Stammdaten
    {
        [Key] public int ID { get; set; }
        public int CardID { get; set; }
}

Was mache ich hier falsch? Gibt es noch Einstellungen, welche ich übersehen habe?

Danke
Patrick

5.657 Beiträge seit 2006
vor 6 Jahren

Hi padde77,

die EF-Entsprechung deines SQLs würde lauten:

var id = _abfrage.Stammdaten.FirstOrDefault(p => p.CardID == CardID).Select(p => p.ID);

So wird nur die ID übertragen, nicht das gesamte Objekt. Das ist offenbar nicht richtig.

Du kannst dir auch das von EF generierte SQL ausgeben lassen.

Ansonsten mußt du mal einem Profiler verwenden, um das Problem einzugrenzen.

Weeks of programming can save you hours of planning

P
padde77 Themenstarter:in
50 Beiträge seit 2011
vor 6 Jahren

Hi Mr.Sparkle,

hab ich auch schon durch, geht nicht.
Von EF kommt das:

SELECT 
    [Extent1].[ID] AS [ID]
    FROM [dbo].[Stammdatens] AS [Extent1]
    WHERE [Extent1].[CardID] = 522

wobei die 522 dynamisch ersetzt wird. Dauert auch ewig. Und auch die Abfrage nur auf die ID ist langsam.

Was noch langsam ist....meine Verzweiflung 😃

Dank dir trotzdem.

Grüße
Patrick

5.657 Beiträge seit 2006
vor 6 Jahren

Hast du es schon mit dem Profiler probiert?
Ist es nur beim ersten Aufruf so langsam, oder auch beim Xten Durchlauf?

Weeks of programming can save you hours of planning

16.807 Beiträge seit 2008
vor 6 Jahren

Von MrSparkle's Hinweisen abgesehen: mit EF wirst Du auch nie die Performance eines reinen SQL Befehls bekommen.
Dafür ist es auch gar nicht gedacht (und auch deswegen nehmen viele mittlerweile Abstand von EF6).
Zum Thema Performance bist Du diesbezüglich bei Deiner Recherche ja sicherlich schon auf viele entsprechende Googletreffer gestoßen.

Mit EF Core hat sich das Serialisierungskonzept geändert, weshalb dieses um ein Vielfaches schneller ist.

P
padde77 Themenstarter:in
50 Beiträge seit 2011
vor 6 Jahren

Hi nochmal.

Welchen Profiler meinst du Mr.Sparkles?
Abt. Dann kann ich mir das EF ja auch gleich schenken.
Ich versteh halt nicht, dass bei einer solch geringen Datenmenge der Unterschied bereits so gravierend ist.
Danke trotzdem.

Grüße
Patrick

16.807 Beiträge seit 2008
vor 6 Jahren

Der Unterschied KANN nicht so gravierend sein; kann ich auch nicht nachvollziehen - außer im ersten Fall natürlich die völlig unterschiedliche Abfrage.

Ich wollte damit lediglich die Erwartungshaltung herunterfahren, dass Du mit dem EF6 in Performance-Regionen eines Plaint-SQL kommst.
Wie gesagt, bei EF Core sieht das schon wieder etwas anders aus; dort war aber Performance auch wichtiger, weshalb dafür andere Features fehlen, die zu teuer waren.

W
955 Beiträge seit 2010
vor 6 Jahren

@padde77
Beantworte erst einmal MrSparkles Frage, ob es nur beim ersten Mal auftritt. EF muss beim ersten Mal das Mapping zwischen DB und Model aufbauen.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Hi der SQL Server hat schon mal "Probleme" mit Parametern (Nennt sich glaube ich Parameter Sniffing).

Um zu schauen ob es daran liegt, kannst du dir mal mit dem SQL Profiler aus dem Managementstudio anschauen. Was für SQL wirklich auf den Server ausgeführt wird und es dann selbst noch mal auf den SQL Server ausführen.

Wenn es daran liegt kannst du dir das mal anschauen:
Parameter Sniffing Problem and Possible Workarounds

Wenn man das Tracking bei EF nicht braucht kann man es Ausschalten. Bingt da schon ein bisschen an geschwindigkeit.
Was du auch beachten solltest ist das EF beim ersten Aufruf deutlich langsamer ist. (Ich denke mal deshalb hat MrSparkle auch die Frage gestellt).

p.s.
0,15s für reines SQL, bei einer Abfragen bei einer Tabelle mit 10 Datensätze, klingt jetzt erst mal langsam.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

T
2.219 Beiträge seit 2008
vor 6 Jahren

@padde77
Meine Vermutung ist folgende.

1.Du hast keinen Index auf die CardID Spalte
2.Du verwendest bei deiner Anweisung Top 1, EF 6 nicht.

Hier ist Top 1 schneller, da die Verarbeitung beim ersten Treffer direkt abbricht während die EF Abfrage ohne Index einen Table Scan machen muss, was enorm lange dauern kann wenn die Tabelle groß ist.

Nachtrag:
Bezeiht sich deine Information mit den 10 Einträgen nur auf die Treffer oder auf den gesamten Tabellen Inhalt.
2,5 Sek. für 10 Einträge scheint mir hier enorm lange.
Deshalb gehe ich mal von den reinen Treffern aus, die Tabelle dürfte aber um einiges größer sein oder?

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
padde77 Themenstarter:in
50 Beiträge seit 2011
vor 6 Jahren

Hi @all,

Dass es beim ersten Aufruf etwas dauern kann, ist klar.
Aber was wir gestern auf einem anderen Rechner mit lokaler DB erlebt haben, ist heftig.
Erster Aufruf ca. 1,5 Sek, die nachfolgenden min 4 Sek mit EF.
Trotzdem werden wir jetzt direkt SQL verwenden.

Danke schön
Patrick

2.207 Beiträge seit 2011
vor 6 Jahren

Hallo padde77,

ich glaube immernoch, dass da was andres reinfunkt. EF ist zwar jetzt nicht das allerschnellste, aber so langsam ist es dann auch nicht...

Gruss

Coffeebean

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Coffeebean
Vermute ich auch.
Ich weiß ja immer noch nicht, wieviele Zeilen die Tabelle hat, ob die CardID einen Index hat etc.
Selbst EF 6 dürfte keine 4 Sekunden an der Abfrage werkeln.
Entsprechend werden uns hier einige Details nicht mitgeteilt.
Wie sollen wir da helfen?

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.