Wie langsam ist Firebird über Internet wirklich?

[tsteinmaurer]

Zwei Optimierungstipps:

* Transaktionshandling aus der Routine rausziehen (wie du richtig erkannt hast), d.h. eine Transaktion starten, Abfragen ausführen, Transaktion mit einem Hard Commit comitten, fertig.
* Verwende eine Prepared-Query, die einmal Prepared wird, mit jedem Aufruf mit den neuen Parameterwerten befüllt and dann ausgeführt wird. So ersparst du dir den ständigen Traffic im Prepare-Schritt der Abfrage

[mkinzler]

Unter Umständen hilft es auch den Verkehr beim Zugriff übers Internet zu Tunneln ( ZeDeBee, stunnel).

[alleinherrscher]

Zitat von mkinzler:

Unter Umständen hilft es auch den Verkehr beim Zugriff übers Internet zu Tunneln ( ZeDeBee, stunnel).

Habe ich mit SSH/putty getestet, hat aber keine Zeit rausgeholt.

@tsteinmaurer Aber ein Commit brauche ich nur beim Ändern von Daten, richtig? Kann ich für verschiedene Lesevorgänge in der db die selbe transaction verwenden?

[MrSpock]

Grundsätzlich brauchst du ein Commit nur nach einem Schreibvorgang. Wichtig ist e aber eine Transaktion abzuschließen (commit oder rollback).

[mjustin]

Zitat von MrSpock:

Grundsätzlich brauchst du ein Commit nur nach einem Schreibvorgang.

Andererseits muss man eine neue Transaktion auch dann beginnen, wenn man bei nur lesenden DB Zugriffen die zwischenzeitlich geänderten Daten sehen will. Die erste Aktion nach einem "COMMIT", "ROLLBACK" oder "CONNECT" beginnt eine neue Transaktion. Was man effektiv wann sieht, hängt noch vom Isolationslevel der Transaktion ab.

[tsteinmaurer]

Zitat:

Aber ein Commit brauche ich nur beim Ändern von Daten, richtig?

Nein. In Firebird läuft alles in Kontext von Transaktionen, auch lesende Zugriffe und auch diese Transaktion muss beendet (Commit/Rollback) werden.

Zitat:

Kann ich für verschiedene Lesevorgänge in der db die selbe transaction verwenden

Natürlich. Mit IBX stopelst dir das eben mit einer TIBTransaction zusammen, die dann von mehreren Query-Komponenten verwendet wird. Über den Isolation-Mode steuerst du dann was die einzelnen Abfragen im Kontext dieser Transaktion von anderen committed Transaktionen "mitbekommen".

Leider kümmern sich die Leute in der Regel kaum um das Transaktions-Management in der Client-Anwendung, ohne deren Auswirkungen zu kennen. Vor allem wenn man neu mit Firebird zu arbeiten beginnt. Das ist auch ein Hauptgrund für Performanceprobleme, wenn man z.B. langlaufende Transaktionen offen hat oder (unbewusst) in einem AutoCommit-Modus fährt, der für jede Abfrage automatisch eine neue Transaktion startet und diese automatisch auch wieder mit COMMIT RETAINING beendet. COMMIT RETAINING über eine längeren Zeitraum ohne regelmäßige HARD COMMITs kann für den Firebird Server eine Spaßbremse werden.

[alleinherrscher]

@tsteinmaurer: Okaydokay, die prepared-querys bringen nochmal eine Sekunde. Jetzt bauche ich noch das Commit ein. Bisheriger Code:

Delphi-Quellcode:

function TDataBaseConnection.IsEMailInDB(CustomerID:integer;EMailDate:tDateTime):boolean;
begin
if not assigned(IsEMailInDBQuery) then
 begin
   IsEMailInDBQuery:=TIBQuery.Create(nil);
   IsEMailInDBQuery.Database:=DB;
   IsEMailInDBQuery.Transaction:=ta;
   IsEMailInDBQuery.SQL.Text := 'SELECT COUNT(*) FROM DOCUMENTS';
   IsEMailInDBQuery.SQL.Add('WHERE CUSTOMER = :CUSTOMER AND MODIFYDATE = :MODIFYDATE');
   IsEMailInDBQuery.Prepare;
 end;

IsEMailInDBQuery.Params[0].AsInteger:=CustomerID;
IsEMailInDBQuery.Params[1].AsDateTime:=EMailDate;
IsEMailInDBQuery.open;
result := IsEMailInDBQuery.Fields[0].AsInteger <> 0;
IsEMailInDBQuery.Close;
end;

//edit: @Steinmaurer: Mit einem ta.commit; am Ende (nachdem IsEMailInDBQuery.Close) macht die Geschichte wieder ca. eine Sekunde langsamer?!