Firebird remote Zugriff über Internet

[raphaelm]

Hallo,

meine Anwendung soll direkt auf eine Datenbank im Internet zugreifen. Dies ist generell kein Problem, jedoch macht die Geschwindigkeit mir sehr zu schaffen.

Was mir bereits aufgefallen ist:

Ein Tunnel z.B via zeebeedee (mit höchster zlib Kompression) bringt zwar Vorteile bei großen Datenmengen, aber verzögert kleine Abfragen).

Das Problem ist weniger die Bandbreite, als die Latenz zwischen Client und Server. Unter 20ms Latenz ist das ganze halbwegs nutzbar. Diese Latenzen sind aber nicht überall machbar.

Es ist kein IBX spezifisches Problem (UIB/IBDAC brauchen ähnlich lange).

Blob Felder sollten wo es geht als varchar mit definierter länge gecastet werden.

Das Netzwerk Protokoll von Firebird 1.5 auf 2.1 auf 2.5 soll ja stark optimiert worden sein. Die Unterschiede fallen hier bei Tests jedoch sehr gering aus. Hier sehe ich das Hauptproblem.

Ich komme leider nicht mit nur einem Query aus
--

Gibt es jemanden von euch, der Firebird über Internet oder VPN erfolgreich mit Latenzen >=50ms und vertretbarer Performance einsetzt. Auf was ist zu achten? Kann man die Antwortzeiten bei Abfragen, wenn notwendig auch über eine Middleware, verringern?

Vielen Dank schonmal
Raphael

[blackfin]

Zitat:

Ein Tunnel z.B via zeebeedee (mit höchster zlib Kompression)

Kann es sein, dass bei vielen kleinen Abfragen ein Grossteil der Latenz durch die hohe Komprimierung und Verschlüssleung der Pakete entsteht?
Kann Zeebeedee Abfragen-Abhängig verschlüsseln / komprimieren?

Ich habe mir für solche Zwecke über die Jahre ein inzwischen recht gut funktionierende Middleware mit Paket-Protokoll geschrieben, bei dem ich solche Sachen selbst in der Hand habe, sprich, auf meinem Server lauscht meine eigene Server-Applikation, die dort lokal an einer Firebird hängt.
Clients konnektieren sich nicht direkt auf die Firebird, sondern auf meine Server-Applikation / Middleware.
Mit dieser kann ich dann über OPCodes und Package-Types steuern, welche der Pakete verschlüsselt werden (bei sehr sensiblen Daten aymmetrisch mit RSA, mittelprächtige symmetrisch Blowfish und unsensible Daten gar nicht) und ebenso, ob das Paket komprimiert wird.

Damit habe ich folgende Vorteile:
1) Ich bin nicht auf das Firebird-Netzwerk-Protokoll angewiesen, das ziemlich aufgeblasen ist
2) Ich kann den Overhead an Paketen minimal halten, je nach Situation, da ich statt Firebird meinen Server befrage, der die Daten dann lokal abfrägt und mir ggf. schon aufbereitet / gestrippt schickt.
3) Ich kann die Geschwindigkeit / Latenz viel besser tweaken, da ich selbst in der Hand habe, was genau übers Netz verschickt wird.
4) Ich kann die Datenbank später ggf. gegen eine andere (mySQL, PostGre etc.) austauschen, ohne dass dies die Clients irgendwie beeinflusst, da die Queries nur über die Middleware lokal auf dem Server ausgeführt werden und die Clients somit nie direkt SQL-Queries schicken, sondern meine Middleware-API verwenden.

Firebird selbst empfiehlt ja auch eine Art von Middleware:

Zitat:

Firebird has a rather heavy network protocol (a lot of chit-chat), so it isn't really comfortable to work accross the Internet. You can use some tunneling software like ZeBeDee, SSH or SSL to encrypt and compress the data, but latency is the main problem as a lot of messages go back and forth (and transfering a lot of small messages over Internet is much slower than one big message).

For this reason it's better to use some middleware or serve the content as web pages (if applicable to your requirements) or use some kind of SOAP.

Was mir noch enfällt ist, manche Abfragen vielleicht auf Stored Procedures auszulagern, falls es geht, das bringt auch manchmal etwas Geschwindigkeit.

[kretabiker]

Hi,

auch wenn meine/unsere Erfahrungen schon einige Zeit zurück liegt/en und zu Zeiten von FB 1.0x mit IBX als Zugriffskomponenten gesammelt wurden: Direkte Verbindungen zwischen Client und Server über das INet sind problematisch. Das von FB verwendete Protokoll ist ziemlich geschwätzig, ständig schnattern beide Seiten miteinander, und wenn es zu einer Verbindungsunterbrechung kommt, gibt es böse Fehlermeldungen und evtl. Datenverlust auf Clientseite, weil Änderungen nicht mehr gespeichert werden können usw.

Wir haben daher für solche Anforderungen (langsame, evtl. instabile Leitungen zwischen Client und Server) umgestellt auf 3-Tier mit den RemObjects-DataAbstract-Komponenten und haben seitdem nur noch selten Probleme. Auch das Antwortverhalten selbst bei größeren Ergebnismengen ist respektabel. Kostet ne Menge, erfordert erheblichen Einarbeitungs-/Lernaufwand und ein etwas anderes Programmiererverhalten, lohnt sich aber meines Erachtens (auch aus anderen Gründen).

Mag sein, dass es andere direkt zugreifende Komponenten gibt, die zumindest das Unterbrechungsproblem auffangen (ich glaube, FIBPlus hat da Funktionalitäten für?), aber dazu weiß ich nichts genaueres und habe keine Erfahrung. Das Geschnatter zwischen Client und Server bleibt bestehen. Wenn dann noch jedes Datenpaket "umverpackt" werden muss für das VPN, sehe ich da schon erhebliche Performanceprobleme.

Viele Grüße

Udo "Kretabiker" Treichel

[raphaelm]

Danke blackfin

Zebedee verschlüssselt und komprimiert Portabhängig und das sehr zügig. Die Ursache liegt definitiv nicht an Zebedee. Kleine Abfragen werden dadurch logischerweise minimal, aber kaum spürbar, verzögert.

Einen solch großen Aufwand mit einem eigenen Protokoll wollte ich erstmal nicht betreiben.

Stored Procedures müssen auch über eine Abfrage ausgeführt und ausgelesen werden (open), was wiederrum in dem selben Problem endet

[raphaelm]

Über das Thema Multitier (mit MIDAS) bin ich auch gestolpert. Ich werde mir die RemObjects-DataAbstract-Komponenten mal genauer anschauen.

Was mich ein wenig stutzig macht sind die Verbesserungen am Netzwerkprotokoll, die bei mir kaum einen Effekt haben:

Zitat:

Please note that Firebird 2.1 has significant improvements to the network protocol (less communication for the same queries), so make sure you use at least 2.1 if you want work over Internet or other slow link.

Auch die Verbesserungen am Netzwerkprotokoll von Firebird 2.5 kommen mir kaum zu gute:

Zitat:

The total times are:
Old protocol(2.1) 55.5s
New Protocol(2.5) 18.5s
New Protocol minus round-trip times of rs3 10.1s

http://asfernandes.blogspot.com/2009...-firebird.html

[tsteinmaurer]

Hallo,

Remote-Protokollverbesserungen setzen allerdings auch den Einsatz der neuesten Client-Library voraus. Hast du mit dem 2.5er Server auch die 2.5er Client-Bibliothek für den Connect verwendet?

lg,
Thomas

[raphaelm]

Ja, es wurde die Client Library aus dem aktuellen Snapshot verwendet und in GDS32.dll umbenannt.

Ich bin derweil ersteinmal so verbleiben, dass ich z.B mehrspaltige Rückgaben von Stored Procedures in einem Query zusammenfasse:

select SP1.*, SP2.* from SP1(<PARAM1>) join SP2(<PARAM2>) on 1 = 1 oder die SQL Abfragen breiter auslege, fetche und dann über locate suche um so ein oder mehrere "Opens" zu umgehen. Eher Dirty Hacks, als anständige Lösungen, aber aufsummiert machen die das ganze jetzt bei ~50ms Latenz benutzbar.