![]() |
Datenbank: Firebird • Version: 2.5.6 • Zugriff über: fbclient.dll
TIBSQL vs isql-fb Shell
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:
Das ganze halt 10.000 untereinander und für isql-fb mit connect ... im Header.
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 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?! |
AW: TIBSQL vs isql-fb Shell
Hall,
tjaaaaaaa. 1. Quellcode des Delphi-Programms fehlt 2. Wo ist denn der Server? Auf dem Linux-Rechner? Falls 2. Zitat:
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. |
AW: TIBSQL vs isql-fb Shell
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. |
AW: TIBSQL vs isql-fb Shell
Hallo,
SQL.Text:= würde ich auf jeden Fall ersetzen durch SQL.Clear; SQL.Add(); Zitat:
ich warte ;) |
AW: TIBSQL vs isql-fb Shell
Zitat:
Ich würde die Abfrage eher parametrisieren. |
AW: TIBSQL vs isql-fb Shell
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 ;) |
AW: TIBSQL vs isql-fb Shell
Zitat:
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. |
AW: TIBSQL vs isql-fb Shell
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. |
AW: TIBSQL vs isql-fb Shell
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? |
AW: TIBSQL vs isql-fb Shell
Hier der Quellcode. Beispiel mit TIBQuery nicht TIBSQL
Code:
Bei dem durchführen auf dem gleichen Rechner (d.h Firebird unter Windows ). Ist der Unterschied 3(isql) zu 7(Delphi) Sekunden.
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; 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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz