MySQL Connector 6.5.4 auf 6.7.4 - Performence Verlust

verwendetes Datenbanksystem: MySQL 5.5.28

Moin !

Ich nutze für unsere Applikation den MySQL Server 5.5.28. Und als MySQL Connector bis dato immer die Version 6.5.4. Nun musste ich VS2012 neu installieren und wollte damit auch den Connector auf die aktuelle Version heben (6.7.4).

Soweit hat das auch alles geklappt, nur ist dadurch alles furchtbar träge geworden. Teilweise 50-100x langsamer (wenn ich mal mein Logging dazu betrachte). Habe dann 6.7.4 wieder deinstalliert und 6.5.4 wieder drauf gemacht. Und schon habe ich wieder die gewohnte Geschwindigkeit.

Hat jemand ähnliches beobachtet? Und gibt es dafür eine Erklärung?

Im 6.7.4-Provider hat sich das Laden von Entitäten etwas verändert, sodass zB das Zusammenspiel mit dem EF 5.0 besser funktioniert. Dieses wird nun auch offiziell unterstützt.
Es kann also sein, dass Deine Queries schon immer suboptimal waren; dies aber wegen dem suboptimalen Handeln von 6.5.4 nie aufgefallen ist bzw. sich aufgehoben hat.

Moin Abt,

soweit sogut, aber ich nutze das EF nicht. Ich nutze in meiner Anwendung nur ganz normale Abfragen mittels Command + Reader. Und die Queries sind nichtmal sonderlich kompliziert. Es gibt so gut wie keine verketteten / verschachtelten Queries. Im Grunde nutze ich nicht viel mehr als ein paar sehr einfache Inserts und Selects die sich immer nur auf eine Tabelle beziehen. So ganz genau wüsste ich nicht was ich da optimieren soll. 🤔

Ich könnte ja auch noch nachvollziehen das es wegen der EF Anpassungen in Summe etwas langsamer wird. Aber in dem Masse kann ich das nicht nachvollziehen.

Muss ich evtl. mein Connection String was mit angeben was bei 6.5.4 mitunter nicht nötig war?

Und mir fällt gerade noch was ein. Ich habe mal testhalber den MySQL Connector von DevArt verwendet. Damit war ein Grossteil um Faktor 2 schneller als mit dem normalen MySQL Connector...

Ist ja egal, ob Du das EF nutzt oder nicht.
Meines Wissens hat der mysql Provider immer direkt materialisiert (zB ein ToList erzwungen) um alle Entitäten sofort zu laden.
Dies ist / war aber nicht im Sinne von ADO.NET.
Prinzipiell ist eine Materialisierung nicht schlimm; das ist auch oft so gewollt - manchmal eben auch kontraproduktiv.
Der Entwickler muss bestimmen können, wann die Ausführung des Queries tatsächlich erfolgen soll, um möglichst performant zu arbeiten.

mysql hatte das am Anfang immer verpennt und nie(?) nachgezogen.
Da sie nun explizit schreiben, dass EF 5.0 supported wird (obwohl wir schon bei EF6.0.2 sind) könnte hier also ein Umdenken bei Oracle stattgefunden haben.

Sprich der Provider legt nun endlich die Logik für das Laden der Entitäten in die Hand des Entwicklers.
Wenn Du jetzt natürlich unvorteilhafte Queries hast, dann resultiert das in einer sinkenden Performance. Statt ständig alles abzurufen wird nun nur das abgerufen, was tatsächlich in diesem Moment gebraucht wird.
Arbeitet man nun mit Schleifen, dann ist das in der Performance kontraproduktiv (könnte also bei Dir der Fall sein).

Beispiel, was bislang bei mysql nie sooo optimal war:

// Referenz auf die Collection. Hier erfolgt kein Abruf auf die Datenbank
IQueryable<MyEntity> allItems = mySqlContext.Entites...BlaBla.

// Schlecht:
foreach( MyEntity item in allItems ) // Bei jedem Schleifen durchlauf wird ein Select auf der DB ausgeführt. 1000 Items = 1000 Selects
{
    // Mach was mit item
}

// Besser:
foreach( MyEntity item in allItems.ToList( ) ) // Einmaliger Query an die DB und ruft sofort alles ab. 1000 Items = 1 Select
{
    // Mach was mit item
}

Ist jetzt aber auch nur Spekulation.
Da Du nicht genau sagst, was Du machst oder zeigst, kann man Dir auch nicht gezielt helfen.

Moin !

Ich poste morgen mal ein paar meiner Queries. Gleich ist erst Nikolausfeier und Sohnemann muss stramm stehen 😁

Statt ständig alles abzurufen wird nun nur das abgerufen, was tatsächlich in diesem Moment gebraucht wird.

Hmm, aber da ich nur ganz normale Queries absetze rufe ich eh nur das ab was ich brauche.

Wie auch immer ... Ich poste morgen mal ein paar meiner Abfragen. Dann schauen wir weiter.