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
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
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
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
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@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.
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:
@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.
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
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
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
@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.