Wie langsam ist Firebird über Internet wirklich?

[mjustin]

Zitat von alleinherrscher:

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.

Das wäre einfach und firewallfreundlich über eine HTTP Abfrage an einen kleinen Anwendungsserver lösbar.

Die HTTP Anfrage würde als Body die Liste der Dokumente enthalten, und de HTTP Antwort je Dokument den aktuellen Status.

Dazu benötigt man nur eine (Indy) HTTP Server Komponente, die auf den DB Server zugreift. Für zusätzliche Sicherheit wie HTTPS oder Zugriffsberechtigungen kann man darüber noch einen Apache HTTP Server schalten, der als Proxy die Internetanfragen annimmt und an das Delphi Programm weiterleitet.

[alleinherrscher]

Zitat von mjustin:

Zitat von alleinherrscher:

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.

Das wäre einfach und firewallfreundlich über eine HTTP Abfrage an einen kleinen Anwendungsserver lösbar.

Die HTTP Anfrage würde als Body die Liste der Dokumente enthalten, und de HTTP Antwort je Dokument den aktuellen Status.

Dazu benötigt man nur eine (Indy) HTTP Server Komponente, die auf den DB Server zugreift. Für zusätzliche Sicherheit wie HTTPS oder Zugriffsberechtigungen kann man darüber noch einen Apache HTTP Server schalten, der als Proxy die Internetanfragen annimmt und an das Delphi Programm weiterleitet.

Huhu, ja okay. Das gesamte Projekt enthält aber mehr als diese (etwas zeitkritische) Abfrage. Ich habe schon mit idTCPServer (lan.fs) und idHTTP gearbeitet. Trotzdem würde ich gerne hier vermeiden, eine solche Lösung implementieren zu müssen, da der Server, auf dem die DB installiert ist, ein Debian Linux ist. Das ist vom Prinzip her kein Problem (mit Free Pascal könnte ich einen kleinen Server schreiben). Aber das wäre echt nur meine allerletzte Maßnahme. Ich glaube, es ist weniger Arbeit, den bereits bestehenden Code notfalls auf eine andere DB wie Postgresql umzubauen. Aber am liebsten würde ich bei Firebird bleiben.

Vom Prinzip handelt es sich bei den Dokumenten um E-Mails auf einem IMAP Server, die ich mit idIMAP4 abrufe und dann lokal speichern möchte.

Grüße,
Michael

[IBExpert]

Moin,

wie hier schon mehrfach erwähnt, bringt jedes execsql oder open immer diverse Datenpakete vom Client zum Server und zurück.
Auch einfach nur mit next durch die Datenmenge zu laufen erzeugt blockweise Traffic.

Da greift jeweils die Latenz, sprich wie lange dauert der Ping. Wenn dein Server auf localhost ist, dann merkst du das nicht,
im lokalen Netzwerk auch eher nicht, weil ping zeit 1ms o.ä., wenn dein Server über gute Leitung mit schneller Ping zeit
extern in irgendeinem Rechenzentrum erreichbar ist, dann geht pro Paket 15-20 ms drauf. Da sind 50 Pakete ca. eine Sekunde.
Ist dein server in Australien, dann sind 300-400ms schon ganz gute Werte, aber 50 Pakete ca. 15-20 Sekunden.

Bei jedem open und execsql kannst du die pingzeit schon mal mit 10 multiplizieren, auch jeder parambyname erhöht das ganze noch mal.

Es hilft also nur, die Anzahl Datenpakete möglichst zu minimieren, genau so machen das auch http Server: Du sendest einen Request
und der Webserver liefert dir einen unidirektionalen Datenstrom, den du lokal auswertest. Wenn du in einer Ajax Webanwendung
einen ähnlichen Quatsch programmierst und jede Zeile im Grid einzeln in eigenen requests abholst, dann läuft das genau so langsam.
Macht man aber bei Webanwendungen nicht freiwillig.

Man kann das auch mit Firebird minimieren, ich hatte dafür hier mal einen kleinen Denkanstoß veröffentlicht:
link

Vielleicht ist das für dich schon passend, die E-Mails, die du abholen willst, liegen ja sicherlich eh als Blob vor. Daher
konstruier dir einfach eine SP, wo du deinen Befehl selbst gestalten kannst und den als Blob parameter zum Server sendest.
Dann hol dir das Ergebnis in einem einzigen Blob zurück, mit von dir definierten Trennern, die du dann ggf lokal wieder
zum auseinandernehmen benutzen kannst. Das gleiche Format kannst du auch im Firebird Server zum senden benutzen:
Nichts hindert dich daran, den Quellcode von 100 E-Mails mit deinem Trenner zusammenzupacken und das als ein Blobparam an
die SP auf dem FBServer zu senden, der die dann lokal wieder mit deinem Trenner auseinander nimmt.
Die Geschwindigkeit ist dann eher durch die Bandbreite der Verbindung limitiert als durch die Ping Zeit.

Per UDF kannst du den Datenstrom dann serverseitig noch komprimieren und Clientseitig ggf mit der gleichen Funktion wieder
entpacken. Solche UDFs kannst du ggf mit Delphi für win32 oder xe2 auch für win64 FB Server in Pascal Code schreiben
(oder auch mit Lazarus, dann auch noch für Linux u.a., wir haben das für Kunden bereits mit lazarus gemacht).

Die Frage ist also eigentlich nicht wie langsam Firebird über das Internet wirklich ist, sondern bist du bereit, die
Möglichkeiten auszunutzen, um den maximalen Speed rauszuholen. Der Umweg über die Blob I/O Prozedur ist eigentlich nichts
anderes als das was Application Server machen, die als Middleware da zwischen gepackt werden. Damit fehlen dann bei Appserver
aber schnell Dinge wie echte Transaktionskontrolle oder du mußt ein weiteres Protokoll implementieren, was dir am ende nicht
wirklich Vorteile bringt. Wenn du das auf Basis der o.a. I/O SP machst musst du wenig neues lernen ....

[alleinherrscher]

Vielen Dank, IbExpert. Ihr habts echt drauf! Okay, dann werde ich mir mal ein bisschen was dazu durchlesen und mal versuchen, die Abfrage in einer Stored Procedure zu erledigen. Ich muss ja auch gar nicht den gesamten EMail-Quelltext übertragen...Zeitstempel und Absender sollten ja auch reichen.

Melde mich wieder, wenn ich was Lauffähiges präsentieren kann oder ich überhaupt nicht weiterkommen sollte.

Besten Dank,
Michael

[hoika]

Hallo,

das prepare bringt nur etwas,
wenn die Query mehrfach mit dem gleichen SQL-Text verwendet wird.
Hier bieten sich Parameter an.
Du erzeugst die Query aber immer wieder ?

Zitat:

Ich habe n Dokumente

Kennst du die Anzahl von n ?
Ist die endlich, kannst du die Abfrage ja dynamisch zusammenbauen.

Hier wäre ein Count(*) zusammen mit Group By möglich.


Heiko

[IBExpert]

bei langsamen Netzwerken mit hoher latenz (Pingzeit) sind parametrisierte querys eher kontraproduktiv, weil mit jedem parameterwert gesondert datenpakete hin uns her geschickt werden. Beim senden eines kompletten sqls wird nur das sql in einem Datenpaket zum server geschickt und dort prepared. was auf schnellen Netzwerken von Vorteil ist kann auf langsamen Netzwerken genau das Gegenteil sein.

[alleinherrscher]

Hallo nochmals. Haben das Problem jetzt mit Stored Procedures gelöst und die sind in der Tat wunderbar schnell, so dass ich nun mit der Geschwindigkeit meines Programms sehr zufrieden bin.

Problem: Ich habe das Abrufen der E-Mails in einem Thread ausgelagert. Innerhalb des Threads wird daher auch die folgende Funktion(s.u.)aufgerufen, die die Datenbank abfragen muss. Es kommt an der Stelle "IsEMailInDBQuery.Transaction:=ta;" zur AccessViolation - aber erst beim zweiten Aufrufen der Funktion.
Zusätzliche Informationen:
- Das Problem taucht nur auf, wenn das Programm mit einer DelphiXE2 Version innerhalb einer VirtualBox gedebugt wird.
- Das Object TDatabaseConnection befindet sich nicht innerhalb des Threads. Ich habe die Funktion IsEMailInDB daher testweise per Synchronize aufgerufen, was aber nichts an der AV ändert.

Delphi-Quellcode:

function TDataBaseConnection.IsEMailInDB_All(aEmailList:EMailList):IsEMailInDB_result;
var i:integer;
    str:string;
    ta: TIBTransaction;
begin

 ta:=TIBTransaction.Create(nil);
 ta.DefaultDatabase:=DB;

if not assigned(IsEMailInDBQuery) then
 begin
   IsEMailInDBQuery:=TIBQuery.Create(nil);
   IsEMailInDBQuery.Database:=DB;

   IsEMailInDBQuery.SQL.Text := 'SELECT * FROM IS_EMAIL_IN_DB(:STR)';
   IsEmailINDBQuery.Prepare;
 end;

 IsEMailInDBQuery.Transaction:=ta;

 str:='';
 for i := 0 to length(aEMailList)-1 do
     str:=str+inttostr(aEMailList[i].customerid)+','+datetimetostr(aEMailList[i].EmailDate)+',';

 str:=copy(str,1,length(str)-1);

 IsEMailInDBQuery.Params[0].AsString:=str;
 IsEMailInDBQuery.open;

 str := IsEMailinDBQuery.Fields[0].AsString;
 setlength(result,length(str));
 for i := 0 to length(str)-1 do
   result[i]:=(str[i+1]<>'0');

 IsEMailInDBQuery.Close;
 ta.free;
end;

Hat jemand eine Idee?

[Lemmy]

Hi,

schau bitte nach, ob der Zeiger auf die Objektstrutkur von IsEMailInDBQuery sich zwischen den ersten und zweiten Durchlauf unterscheidet. Bitte Kontrollier auch, ob Du IsEMailInDBQuery zwischen durch irgend wo freigibst ohne den Zeiger zu nillen...

[alleinherrscher]

Zitat von Lemmy:

Hi,

schau bitte nach, ob der Zeiger auf die Objektstrutkur von IsEMailInDBQuery sich zwischen den ersten und zweiten Durchlauf unterscheidet. Bitte Kontrollier auch, ob Du IsEMailInDBQuery zwischen durch irgend wo freigibst ohne den Zeiger zu nillen...

Huhu! Dies habe ich schon getan. Ich kann auch in der Quelltextzeile vor EMailAdressToCustomerIDQuery.Transaction:=ta auf IsEMailInDBQuery zugreifen und z.B. den ClassName ausgeben. Funktioniert wunderbar.

[Lemmy]

könntest Du dann mal die Stelle hier ändern bzw. die Transaction in der Query Nillen? Schau dir ggf. auch mal an was im Code bei der Query passiert, wenn DU ne Transaction setzt.

Delphi-Quellcode:

 IsEMailInDBQuery.Close;
 IsEMailInDBQuery.Transaction:=nil;
 ta.free;