TIBSQL vs isql-fb Shell

[stalkingwolf]

Ich habe zu Performancetest einmal 10.000 Datensätze in eine Textdatei gespeichert und diese einmal in in einem Delphi Programm in einer Schleife mit TIBSQL ausgeführt und einmal auf der Shell ( Linux ) mit isql-fb .

Die SQL Anweisungen waren nichts anderes als:

Code:

INSERT INTO MYTABLE (FELD_SNR, FELD_1,FELD_2, FELD_3,FELD_4) VALUES( GEN_ID(GEN_MYTABLE_SNR,1), '1', '2', '3', '4');

Das ganze halt 10.000 untereinander und für isql-fb mit connect ... im Header.

Das Delphiprogramm (6, XE4, 10.1 ) benötigte dafür 30 Sekunden Client -> Server 1GBIT Netzwerk.
Auf der SHELL von Linux per isql-fb 3 Sekunden.

Mir war schon klar das über das Netzwerk aus deinem Delphiprogramm es langsamer sein wird. Aber Faktor 10?
Das ist übrigens in allen Konstellationen reproduzierbar auf verschiedenen Servern und verschiedenen Umgebungen z.b VMWare virtuelles Netzwerk 10GBIT.
Dabei fällt auf das sowohl Server als auch Clientprogramm sich langweilen. Ich komme auf evtl 6-7% CPU Auslastung auf dem Server und 10% auf dem Client (Windows 7/8/10).

Normal? Optimierungspotential? Falls ja, wo?!

[hoika]

Hall,
tjaaaaaaa.

1.
Quellcode des Delphi-Programms fehlt

2.
Wo ist denn der Server?
Auf dem Linux-Rechner?


Falls 2.

Zitat:

Mir war schon klar das über das Netzwerk aus deinem Delphiprogramm es langsamer sein wird. Aber Faktor 10?

Dir ist schon klar, dass 10.000 Prepares übers Netz laufen.
Zusätzlich zu den 10.000 Executes.
Und dass es bei isql unter Linux statt zu IP-Zugriffen zu Local-IP (jaja, das heisst unter Linux anders! ;) ) führt.

Wenn du fair wärst, würdest Du den Server zusätzlich unter Windows installieren und auch das isql benutzen.

[stalkingwolf]

beim aufbereiten des Codes zum posten ist mir eins aufgefallen.
von den 30 Sekunden benötigt das füllen von mysql.sql.text := sqlcode alleine 20sek.
D.h wenn ich die Schleife ohne execsql durchlaufe, braucht das ganze noch 20sek.
Das füllen von sql.text von TIBQuery oder TIBSQL ist das langsame.
Ich werde das morgen weiter testen und dann Quellcode posten.

2.) Firebird SQL 2.5.5 auf einem Suse Linux. Egal ob Classic oder Superserver

3.) ist ebenfalls egal. Haben wir auch getestet. Firebird Server unter Windows auf der gleichen Maschine auf welcher das Clientprogramm läuft. Auch 30sek.
ibsql-db auf der Windows Kiste habe ich aber nicht getestet.

[hoika]

Hallo,

SQL.Text:=
würde ich auf jeden Fall ersetzen durch
SQL.Clear;
SQL.Add();

Zitat:

von den 30 Sekunden benötigt das füllen von mysql.sql.text := sqlcode alleine 20sek.

Das ist ein lokaler Aufruf, der auf meinem 486-er (Turbo !!!) gerade mal 50 msec braucht ... ;)

ich warte ;)

[mkinzler]

Zitat:

würde ich auf jeden Fall ersetzen durch

Und Warum? Um es noch langsamer zu machen?
Ich würde die Abfrage eher parametrisieren.

[hoika]

Hallo,
es geht doch (hier) um einen direkten Vergleich eines Delphi-Programmes und der Konsole.
Es wäre doch unfair gegenüber der Konsole, mit Prepare zu arbeiten ;)

[stalkingwolf]

Zitat:

Zitat von mkinzler (Beitrag 1431306)

Zitat:

würde ich auf jeden Fall ersetzen durch

Und Warum? Um es noch langsamer zu machen?
Ich würde die Abfrage eher parametrisieren.

Das funktioniert in diesem Fall nicht. Es ist eine große ASCII Datei mit 10.000 SQL Befehlen ( insert ) die nur in der Schleife ausgeführt werden sollen.

Ich habe mittlerweile die meisten Performanceproblem Quellen gefunden.
Es war zum einen der mehrmalige Zugriff auf sql.text ( auch wenn es nur 50ms sind. Das mal 10.000 summiert sich und ich brauch das nachher eher in der 1.000.000 Region ).
Dann meine Logs welchen jede executetime in ein TMemo geschrieben hat zum auswerten.

Ich habe nun die reine Executezeit mit gettickcount davor und danach summiert und liege bei 11 Sekunden.

[Fritzew]

Wie sieht es mit den Transactions aus?
Starte eine Transaction explicit für Deine TIBSQL
nach dem ausführen natürlich das Commit nicht vergessen.

[hoika]

Hallo,
mir fehlt immer noch der Quellcode des Delphi-Programms.
Das ISQL arbeitet doch bestimmt so clever,
dass er die Inserts nicht jedesmal zusammenbaut,
sondern sich merkt, dass es der gleiche Befehl ist.
Inwiefern da Prepare's benutzt werden, weiß ich nicht.

Und noch mal meine Frage:
Laufen beide Programme auf dem gleichen Rechner?

[stalkingwolf]

Hier der Quellcode. Beispiel mit TIBQuery nicht TIBSQL

Code:

procedure TForm1.bbexecClick(Sender: TObject);
var i,j         : integer;
    q           : TIBquery;
    command,
    line        : string;
    start,summe,
    t1,t2       : cardinal;

begin

    if input.lines.text = '' then exit;
   
    ibdb.DatabaseName := edDatabase.Text;
    ibdb.Connected    := TRUE;
    ibtrans.Active    := TRUE;

    bbexec.enabled    := FALSE;

    sb1.Panels[0].Text := ibdb.DatabaseName;
    caption := application.Title + ' - '+ibdb.DatabaseName;

    q:=tibquery.create(nil);
    q.UniDirectional:=FALSE;
    q.database      :=ibdb;

    output.lines.Clear;

    pb1.Position    := 1;
    pb1.Max         := input.lines.count;
    command         := '';
    summe           := 0;

    output.lines.add(format('%s - %s : Starte',[datetostr(date),timetostr(now)]));
    start := gettickcount;
    for i := 0 to input.lines.count -1 do begin

        pb1.Position:=i+1;

        command:=command+input.lines[i];

        if pos(';',input.lines[i]) = 0 then continue;

        try
            command:=stringreplace(command,#13#10,'',[rfReplaceAll]);
            command:=stringreplace(command,#13,'',[rfReplaceAll]);
            command:=stringreplace(command,#10,'',[rfReplaceAll]);


            q.sql.text  := command;
            command     := '';
            t1          := GetTickCount;
            q.open;
            t2          := getTickcount;
            summe       := summe+(t2-t1);
            output.lines.add(format('EXEC Time : <%d>',[(t2-t1)]));

            if q.eof then begin
                output.lines.add('EOF : '+q.sql.text);
            end else begin

                while not  q.eof do begin
                    line:='';
                    for j:=0 to q.FieldCount -1  do begin
                        if j = 0 then line:=q.FieldList[j].AsString
                        else line:=line+';'+q.FieldList[j].AsString;
                    end;
                    output.lines.add(line);
                    q.next;
                end;
            end;

        except
            on e:exception do begin
                output.lines.add(e.message);
            end;
        end;

        q.close;
    end;

    output.lines.add(format('%s - %s : Dauer Programm : %s sec ',[datetostr(date),timetostr(now),floattostr((gettickcount-start) / 1000)]));
    output.lines.add(format('%s - %s : Dauer Execute  : %s sec ',[datetostr(date),timetostr(now),floattostr((summe) / 1000)]));

    if ibtrans.Active then ibtrans.CommitRetaining;


    output.lines.add(format('%s - %s : Ende ',[datetostr(date),timetostr(now)]));
    Application.ProcessMessages;

    q.free;
    bbexec.enabled:=TRUE;
    ibtrans.Active:=FALSE;
    ibdb.Connected:=FALSE;
end;

Bei dem durchführen auf dem gleichen Rechner (d.h Firebird unter Windows ). Ist der Unterschied 3(isql) zu 7(Delphi) Sekunden.

Letztendlich hat sich das ganze nun so gut wie geklärt. Ich habe nicht gedacht das die Interaktion mit der UI so extrem langsam ist. Ich habe dies nun auf einigen System (PC, VMWare Client, Hyper-V System ) getestet und es schwankt enorm.
Auf Hyper-V Systemen ist die Diskrepanz am größten.

[hoika]

Hallo,
sehr gut.

Zitat:

output

das ist ja jetzt hoffentlich eine Stringlist und kein Memo?

5 Sachen sehe ich.

Zitat:

q.UniDirectional:=FALSE;

True setzen, du willst in der Query doch nicht per Prior zurücklaufen.

Zitat:

pb1.Position:=i+1;

Wieder ein Oberflächenelement, was sich 10.000 neu zeichnet
mache lieber sowas wie

Delphi-Quellcode:

if (i div 100)=0 then
begin
  pb1.Position:=i+1;
end;

also nur jeden 100. Eintrag zeichnen.
Wenn Max auf 10.000 steht, fällt ein Pos+1 nicht auf.

Zitat:

q.open;

Das habe und den ganzen Block mit dem q.eof habe ich überhaupt nicht verstanden.
Ein Insert wird über q.ExecSQL ausgeführt.

Zitat:

GetTickCount

Du ermittelst die Laufzeit jedes einzelnen Inserts.
Also 20.000 GetTickCounts.

[mkinzler]

Warum führst Du das gesammte Skript nicht komplett aus und zerlegst es in einzelne Abfragen?

[stalkingwolf]

Mir war klar das der Quellcode an Stellen auseinander genommen wird die keine Relevanz haben.
Daher hatte ich ihn nicht gepostet.

Aber zu den 5 Punkten oben.
1.) unidirectional stand vorher auf TRUE. Macht keinen Unterschied.
2.) Resultat soll direkt sichbar sein. Macht aber keinen Unterschied.
3.) siehe 2.
4.) Das Programm führt nicht nur insert, delete sondern auch select aus. Falls es ein select ist, wird die Ausgabe ausgegeben. Daher open und nicht execquery. Macht in meinen Test aber keinen Unterschied.
5.) Das ist doch der ganze Sinn der Sache.

@mkinzler
Siehe Punkt 3 und es ist ein gezielter Performancetest auf viele SQL Anweisungen.

[hoika]

Hallo,
Punkt2 ist der Progressbar.
Natürlich macht es einen Unterschied, ob ich einen Befehl 10.000 mal
oder 100 mal ausführe.
An der Oberfläche sieht man natürlich nichts.

Das mit dem Select habe ich nicht verstanden,
wozu soll das gut sein?
Kommt da irgendwas aus der DB und muss verarbeitet werden?

Unidirectional
https://www.devart.com/ibdac/docs/de...irectional.htm

Ist denn da Ergebnis von isql das gleiche wie im Delphi-Programm,
halt nur schneller, oder wird dort weniger ausgegeben?

[jobo]

Vorweg, ich hab den Code nicht angeschaut.

@hoika: Ich denke, es geht dem TE mit dem Open/Select um einen qualitativ realistischen Testcase, der zwecks Mittlung eben ein Volumen von 10000 Statements hat. Also echtes Select usw.

@TE: Dir muss bei einem solchen Vergleich schon bewusst sein, dass Du die berühmten Äpfel mit den ebenso berühmten Birnen vergleichst:

Die nahezu Abwesenheit von GUI in einer Concole ist schon mal offensichtlich.
Ähnlich die GUI Nutzung im Detail und mit ihrer zeitlichen Wirkung- wie schon geschrieben. GUI Zeichnen dauert, mit einer schlechten Graka notfalls lange.
Aber auch ohne GUI hast Du einen Effekt durch die Query selbst und wie sie die 10000 Einzelergebisse handhabt, wie u.a. auch der Hinweis auf Uniderectional zeigt. Du führst 10000 Operationen mit individuellen Folgeoperationen, Speicherallokationen usw. aus. Die Console schiebt stumpf die Statements an den Server, der gibt ASCI/UNI -CODE zurück, fertig, alles en block. Da wird am Client nichts allokiert, created, destroyed. Der Client haut die Zeichen auf den Screen, fertig.
IdR. ist eine Query Komponente nicht mal in der Lage, ein Script(mehr als einen Befehl hintereinander) auszuführen. Dafür gibt es separate Scriptkomponenten.

[hoika]

Hallo,
schön zusammengefasst von jobo ;)

[IBExpert]

Zitat:

Zitat von jobo (Beitrag 1431373)

IdR. ist eine Query Komponente nicht mal in der Lage, ein Script(mehr als einen Befehl hintereinander) auszuführen. Dafür gibt es separate Scriptkomponenten.

Einspruch, zumindest für Firebird >=2.x kannst du mehrere insert/update/delete Befehle semikolon getrennt zB in einer TSTringlist sammeln, dann schreibst du EXECUTE BLOCK AS BEGIN davor und ein END dahinter und schon kannst du mit nahezu jeder SQL Query Komponente mehrere Befehle auf ein mal senden (Bei manchen Komponenten musste du deren interne Prüflogik abschalten, wenn die zu blöd sind, execute blocks korrekt zu erkennen).

Das beschleunigt die Ausführung noch mal erheblich, hat aber ein paar Grenzen (maximal 255 Relationen pro block, also 255 inserts oder 127 updates oder 85 "update or insert", gerne aber auch gemischt, als Richtwert einfach maximal 80 Befehle pro Block, gesamter source kleiner als 32k,...)

Bei solchen Anforderungen bringt das erhebliche Geschwindigkeitsvorteile aus einer Delphi/Lazarus Anwendung, aber wie die anderen schon sagten, man sollte bei der Geschwindigkeitsmessung die Zeit nicht verplempern mit visualisierungen, es bringt dir nix an Erkenntnissen zur Optimierung deiner SQL Operationen, wenn die SQLs am ende für 1% der Laufzeit verantwortlich sind und 99% irgendwelche TMemos auf dem Screen vertrödeln

Außerdem nicht vergessen, wenn es um High Speed geht, hilft auch die Benutzung des lokalen Protokolls xnet oder noch schneller importe per external tables ...

Aber mal ganz ehrlich, dein Source ist aus meiner Sicht nicht annähernd hilfreich, um den SQL Speed neutral zu bewerten, dafür solltest du klarer trennen zwischen Zeitaufwand für das senden der SQL Befehle und irgendwas anzuzeigen. Nicht vergessen, 10000 mal 1ms sind 10 Sekunden

[jobo]

Einspruch zum Einspruch.

Was Du beschreibst, ist eine Fähigkeit des Servers, nämlich einen Anonymous Block ausführen zu können, also im Prinzip eine Stored Procedure ohne Signatur / Header. Diese Fähigkeit hat nichts mit der Query Komponenten und ihre Bestimmung zu tun. Sie ist ein Servermerkmal, wie es ähnlich auch bei anderen Server vorzufinden ist, keine Fähigkeit der Query Komponente.

Das hat nichts mit einem Script zu tun, wie man dann den von Dir genannten Einschränkungen auch entnehmen kann und wie sie auch dem TE mit 10000 Inserts nicht helfen würden für seinen Test bzw. Vergleich.

Ich bleibe dabei, um das Verhalten einer Konsole nachzustellen oder vergleichbar zu machen, bräuchte man eine entsprechende Script Komponente.

ot (nur weil es mir wichtig scheint)
Was alles nichts daran ändert, dass ich ein großer Freund von anonymous blocks bin. Sie verleihen eine riesen Power, nicht nur hinsichtlich Roh-Performance auch beim impliziten Transaktions Handling und damit Ressourcen schonenden DML. Hab ich an anderen Stellen schon vielfach betont. Dieses Feature macht auch Firebird zu einem sehr sympathischen System.

Dennoch für den TE zum Verständnis vielleicht ein hilfreicher Vergleich. Die Funktionsweise eines anonymous block, bei der alle Statements ohne Interaktion mit dem Client stumpf auf dem Server ausgeführt werden, verdeutlicht ganz gut die Unterschiede und liefert eine Erklärung für die geringere Geschwindigkeit, bei schrittweiser Ausführung auf dem Client. Jegliches Feedback zum Client entfällt (außer am Ende, z.B. nach dem 255. Insert), keine Allocs, keine Latenzen (die besonders jenseits von MBit/ GBit LAN übel aufstoßen können.
/ot