Wie langsam ist Firebird über Internet wirklich?

[RWarnecke]

Zitat von alleinherrscher:

Ruft das Teil immer die ganze Tabelle ab?

Jepp. Eine Query ist hier besser.

[tsteinmaurer]

Zitat:

Ruft das Teil immer die ganze Tabelle ab?

Dafür kenne ich IBX zu wenig, aber könnte gut sein. Darum auch der Tipp in Bezug auf Monitoring etc. um von Anfang an etwas im Köcher zu haben.

[shmia]

Mit einer Query sieht das ganz grob so aus:

Delphi-Quellcode:

query.SQL.Text := 'SELECT COUNT(*) AS Anzahl FROM DOCUMENTS';
query.SQL.Add('WHERE CUSTOMER = '+QuotedStr(inttostr(CustomerID))+' AND MODIFYDATE = '+QuotedStr(DateTimetoStr));
ShowMessage(query.SQL.Text); // zum Debuggen die SQL-Abfrage anzeigen
query.open;
result := query.Fields[0].AsInteger <> 0;

Das lässt sich mit Parametern noch verbessern sollte so aber auch funktionieren.

[Lemmy]

Hi,

als Jeff Overcash die IBX vor über 10 Jahren veröffentlicht hat, hat er auch 2 Dinge klar gestellt:

1. TIBTable ist lediglich für die Abwärtskompatibilität da, d.h. sollte nur für Umstellungen (d.h. von DBase, Paradox usw. nach Interbase) verwendet werden und dann durch TIBQuery oder TIBDataSet ersetzt werden
2. IBX werden Firebird nicht unterstützen.

Die IBX funktionieren zwar meistens mit Firebird, aber es wird halt nicht offiziell unterstützt, d.h. kann auf Besonderheiten nicht eingehen.

Wenn es dir nur mal um den GEschwindigkeitsunterschied geht, nimm mal die UIB, bzw. wenn es später um "einfache" Datenbankanwendungen geht (d.h. Datenbank-Query-Datasouce-DBKomponente) dann auch die kommerziellen FIBplus oder IBDAC (gibts sicherlich auch Testversionen von denen). Die funktionieren auch mit den aktuellen Firebird-Versionen ohne "Tricks".

Wenn Du bei Firebird bleiben willst, gibts eine einfache Möglichkeit die Performance rasant zu steigern: Übertrag die Abfrage als Text auf einen "Anwendungsserver" der im lokalen Netz beim FBServer steht (oder direkt auf der selben Maschine läuft), führ die Abfrage dann dort "lokal" aus und übertrag das Ergebnis wiederum per TCP/IP Verbindung an den eigentlichen Client. Dazu hat sich auch mal einer Gedanken gemacht und ein Framework geschrieben, das find ich aber auf die schnelle nicht, oder doch:

http://leonardorame.blogspot.de/2009...work-part.html

da gehts zwar gleich um Objekte, aber auf eine vergleichbare Art und weise kannst Du ja auch ein Abfrageergebnis übertragen...

GRüße

Grüße

[alleinherrscher]

Zitat von shmia:

Mit einer Query sieht das ganz grob so aus:

Delphi-Quellcode:

query.SQL.Text := 'SELECT COUNT(*) AS Anzahl FROM DOCUMENTS';
query.SQL.Add('WHERE CUSTOMER = '+QuotedStr(inttostr(CustomerID))+' AND MODIFYDATE = '+QuotedStr(DateTimetoStr));
ShowMessage(query.SQL.Text); // zum Debuggen die SQL-Abfrage anzeigen
query.open;
result := query.Fields[0].AsInteger <> 0;

Das lässt sich mit Parametern noch verbessern sollte so aber auch funktionieren.

@Shima: Okay, die Benutzung von TIBQuery hat die Dauer der Abfrage von 20 Sekunden auf 5 Sekunden verringert. Das ist doch schonmal ein Anfang. Danke!!

@RWarnecke: Denkst du, dass Stored Procedures das ganze schneller machen, als die eine TIBQuery Abfrage von Shmia? Hier wird ja auch nur noch eine einzige Zahl an den Client übermittelt.

@Lemmy Danke für die Tipps. Ich werde Tibtable nicht mehr verwenden. Ich habe auch schon daran gedacht, einen TCP Server zu verwenden, der die DB lokal ansteuert. Habe die Idee aber zunächst verworfen, da der Server ein Debian System ist und ich dann den FPC verwenden müsste + sehr viel Arbeit für das kleine Programm.

Macht es sinn, in meiner Funktion, die 20 mal aufgerufen wird, jedes mal eine neue Transaction zu erstellen und diese hinterher wieder zu zerstören? Wäre es schneller/sinnvoller, die transaction nur einmal zu erstellen?

[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?

[RWarnecke]

Zitat von alleinherrscher:

@RWarnecke: Denkst du, dass Stored Procedures das ganze schneller machen, als die eine TIBQuery Abfrage von Shmia? Hier wird ja auch nur noch eine einzige Zahl an den Client übermittelt.

Ich bin noch nicht ganz dahinter gestiegen, warum Du diese Funktion so oft aufrufst. Eine Stored Procedure führt alles auf dem Datenbankserver aus und gibt dann das Ergebnis zurück. Das heißt es wird nicht x Mal der Select-Befehl an den Server geschickt.

[alleinherrscher]

Zitat von RWarnecke:

Zitat von alleinherrscher:

@RWarnecke: Denkst du, dass Stored Procedures das ganze schneller machen, als die eine TIBQuery Abfrage von Shmia? Hier wird ja auch nur noch eine einzige Zahl an den Client übermittelt.

Ich bin noch nicht ganz dahinter gestiegen, warum Du diese Funktion so oft aufrufst. Eine Stored Procedure führt alles auf dem Datenbankserver aus und gibt dann das Ergebnis zurück. Das heißt es wird nicht x Mal der Select-Befehl an den Server geschickt.

Ich habe n Dokumente (sagen wir charakterisiert durch einen String und eine DateTime - z.B. eine EMail) und möchte wissen, ob diese Dokumente schon in der Datenbank vorhanden sind.