Updates mit Zeos/MySQL dauert zu lange?

[dbdeath74]

Hallo,

ich hänge gerade eine Applikation von MSSQL Server auf mySQL um.
Nun dauert etwas was mit MSSQL 1s dauert auf einmal 6s

Etwas langsamer sehe ich ja ein, aber Faktor 6? Kann das sein?

Es sind folgende Updates, die Pro Gerät ca 100mal ausgeführt werden.
Wie ich herausgefunden habe ist es der Update Befehl der so lange brauch.
Die Operationen auf dem lokalen Dataset habe ich ja bei MSSQL auch, das sollte nicht der Faktor sein.

Ich gehe auf den Primary Key der Tabelle, der indiziert ist.
Irgendjemand eine Idee wie man das verbessern könnte?

Delphi-Quellcode:

    // wenn Update eines Gerätes dann prüfe ob Software schon vorhanden
            If DSSoftwareGeraet.DataSet.Locate('SoftwareID; VersionID',VarArrayOf([
              intToStr(SoftwareID) ,IntToStr(VersionID)]),[loCaseInsensitive]) then
            begin
              // Falls ja aktualisiere LastScan Datum
              ScanID := DSSoftwareGeraet.DataSet.FieldByName('ID').AsInteger;
              Close;
              SQL.Clear;
              SQL.Add('UPDATE CMDB_Software_Scan SET LastScan ='+QuotedStr(DateTimeToStr(scanDate)));
              SQL.Add(', Aktiv = 1');
              SQL.Add(' WHERE ID = '+IntToStr(ScanID));
              ExecSQL;
            end;

Gruß Oliver

[Bernhard Geyer]

Wie groß ist die Tabelle CMDB_Software_Scan?
MySQL ist bei der Installation sehr zurückhaltend was den maximal verwendeten Hauptspeicher angeht im Gegensatz zu anderen DBMS die bei Bedarf oder auch sofort allen möglichen Speicher sich reservieren.

[dbdeath74]

Hallo,

momentan sind es erst 2500 Datensätze, da ich noch in der Testphase bin.
Im Betrieb werden es wohl maximal 50-100k Datensätze werden.

Was mir aber gerade noch aufgefallen ist, ein Insert dauert genausolange oO

Also wenn ich statt 100 updates auf die Tabelle 100 Inserts mache.
Das macht für mich jetzt gar keinen Sinn mehr

Ein INSERT sollte doch viel schneller gehen oder?

Ich hatte es am Anfang auch erst mit mySQL-Connector ODBC Treibern und ADO Komponenten versucht, das war auch so lahm.
Deswegen bin ich auf Zeos gegangen, mit der Hoffnung das es damit schneller ist als über den riesigen ODBC Umweg.

Aber leider Fehlanzeige

Gruß Oliver

[Bernhard Geyer]

Was passiert wenn Du z.B. mit dem MySQL Query Browser das Statement direkt absetzt.
Wir unterstützen selbst MySQL und MS-SQL und haben bei "normalen" DB-Größen keine großartigen Geschwindigkeitsunterschiede festgestellt. Und ZEOS sollte auch nicht mehr so langsam sein.

[hoika]

Hallo,

ich denke nicht dass das Update das Problem ist,
sondern das Locate (oder fehlender Index).
Eretze das doch mal durch
"Select ScanId From Where SoftwareID=:SoftwareID and VersionID=:VersionID"

Optimale Performance erhälst du hier durch eine Stored Procedure,
die das "Select " auf dem Server ausführt und somit nur ein Befehl übers Netz geht.

Weiter solltest du prüfen, ob auf den beiden Feldern auch Indizes liegen,
sonst wird ja ein full table scan aus dem Select.


Heiko

[dbdeath74]

Hallo,

Die Felder sind indiziert, aber in diesem Fall mache ich ja den Locate auf dem lokalen Dataset, das hat gar nichts mit dem Server zu tun.
Das mache ich absichtlich um den Server zu entlasten, vor allem da ich sicher sein kann das ich der einzige bin der auf die Datenbank schreibend zugreift.

Ich hatte das bei der Optimierung der Applikation für den MSSQL Server mal eingeführt, da ich feststellen musste das meine Anwendung immer auf den MSSQL Server warten muss und nicht voll ausgelastet ist.

Hat mir damals Geschwindigkeitsvorteile gebracht. Aber wie gesagt, das lokale Dataset, das bei mySQL und MSSQL Version gleich ist, kann ja nicht für den Geschwindigkeitsunterschied verantwortlich sein.

Ein Update im Query Browser abzuschicken wird nicht viel bringen, es ist ja nicht das einzelne Update das solange dauert, sonder halt 100 davon.

Nach dem Tip mit dem Speicherverbrauch habe ich mir mal die Einstellungen angesehn des mySQL servers (Standardinstallation), und es war wirklich sehr wenig Speicher allokiert.

Also habe ich mal unter General Parameters die Memory Usage und unter InnoDB das Memory hochgedreht. Nach dem Neustart des Dienstes(der ewig braucht) hat es wohl irgendwas zerschossen *grr Alle InnoDB Tabellen gehen gar nicht, da InnoDB anscheinend nicht mehr geht. Muss mal schauen was er jetzt für Probleme hat, so viel höher hatte ich das Memory gar nicht gedreht, insgesamt immer noch nur ca 1/3 des max verfügbaren Speichers.

Hat jemand Tips zu den Einstellungen?

Gruß Oliver

[Bernhard Geyer]

Zitat von dbdeath74:

Ein Update im Query Browser abzuschicken wird nicht viel bringen, es ist ja nicht das einzelne Update das solange dauert, sonder halt 100 davon.

Ach da ist noch eine Schleife drüber? Dann schnelle deine Query auf parametrisierte Abfrage umstellen und Preparen. Sollte einiges bringen (auch beim MS SQL-Server)

[hoika]

Hallo,

zu mysql kann ich nichts sagen,
aber, wen du 100 mal die Query aufrufst,
muss der Server 100mal die Query parsen und einen SQL-Plan erzeugen.
Benutze mal prepared Queries.

Bsp:

zuerst preparen, dass kann man auch mit dem Aufruf verbinden,
indem die InsertQuery zuerst NIL ist,
und bei =NIL erzeugt und prepared wird

Delphi-Quellcode:

with InsertQuery do
begin
  SQL.Clear;
  SQL.Add('UPDATE CMDB_Software_Scan SET LastScan =:ScanDate, ');
  SQL.Add(', Aktiv = 1');
  SQL.Add(' WHERE ID = :ID'
  Prepare;
end;

und Nutzung

Delphi-Quellcode:

with InsertQuery do
begin
  ParamByName('ScanDate').AsDateTime:= scanDate;
  ParamByName('Id').AsInteger:= ScanId;
  ExecSQL;
end;

Wie du siehst, wird eine eigene Query benutzt.

Bei Firebird bekommt man hier in der Regel 100% mehr Performance.


Heiko

[dbdeath74]

Zitat von hoika:

Hallo,

zu mysql kann ich nichts sagen,
aber, wen du 100 mal die Query aufrufst,
muss der Server 100mal die Query parsen und einen SQL-Plan erzeugen.
Benutze mal prepared Queries.

Heiko

Hallo,

danke für den Tip
Hört sich sinnig an *g

Werde das mal bei meinen ADO Querys mit MSSQL testen (da gibt es prepared).

Bei den Zeos Querys die ich für den mySQL verwende finde ich es leider nicht
Auch nichts was sich anhört als würde es in Richtung prepare gehen *gr.

Weiß jemand wie man Zeos Querys für mySQL preparen kann?

Gruß Oliver

[hoika]

Hallo,

so wie es in den Quellen (6.5.1. Alpha) aussieht,
wird immer prepared.
Ab 4.1 wird das Prepare von mysql übrigens erst unterstützt.

Solange das Statement sich nicht ändert,
bleibt die Query prepared.
Das heisst in deinem Fall, einfach eine parametrisierte Query
benutzen und den SQL-Text NICHT jedesmal zuweisen,
oder anderes gesagt.
Nimm eine separate Query, schreibe den SQL-Text (parametrisiert) einmal rein
und rufe dann immer nur Open bzw. Execute auf.


Heiko
PS: es muss doch auch nen SQL-Monitor geben,
wo man das Preparen der Query sehen kann.
Ich gehe ohne den sqlmonitor gar nicht ausser Haus