Firebird in schlechten Netzwerken

[olaf]

Hallo Leute,

könnt Ihr mir sagen wie sich Firebird in schlechten Netzwerken, wie zum Beispiel WLAN oder einer alten ISDN Verbindung verhält. Ich benutze jetzt turbodb und habe echte Probleme, sobald auch nur 2 Clients mit der Datenbank arbeiten läßt die Performance sehr nach. Hat Firebird dort bessere Werte?

olaf

[blackfin]

Wie kann man das mit der "schlechten Performance" verstehen?
Wenn das Netzwerk schlecht ist und somit der Durchsatz mies ist, dann liegt es ja nicht an der Datenbank, wenn die Daten zu langsam ankommen, sondern eben am Netzwerk.
Da nützt dann auch die schnellste Multiuser-Datenbank nichts, weil der Flaschenhals das schlechte Netzwerk ist.
Wenn dann auch noch mehrere Clients gleichzeitig vom schlechten Netzwerk aus auf die Datenbank zugreifen, dann teilen die Clients sich ja auch noch die miese Bandbreite.
Was soll dann da eine andere Datenbank bringen?

Natürlich gibt es schlechte und gute DB-rotokolle mit wenig und viel Overhead.
Aber es bringt eigentlich eher etwas, clientseitig so viel wie es geht lokal zu cachen (falls möglich), oder die Anzahl der Abfragen zu minimieren, falls das Protokoll wirklich so ins Gewicht fällt.

[mquadrat]

Ich sag mal es gibt schnellere Protokolle als das, das Firebird nutzt. Aus der offiziellen Firebird FAQ

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.

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.

[stahli]

Nur mal, um auch das Undenkbare anzusprechen:

Falls Du TTable benutzt und durch die Tabelle rödelst, könnte eine Einsatz von Querys (SQL-Statements) vermutlich mehr bringen als ein Wechsel der DB.

[mjustin]

Zitat:

Firebird has a rather heavy network protocol ...

For this reason it's better to use ... or use some kind of SOAP.

Also ist SOAP schlanker als das Firebird Protokoll? YMMD!

Cheers,
Michael

[mquadrat]

Naja, immerhin gibt es da nur einen Request und einen Response. Wenn Firebird wirklich so viel hin und her schickt, dann könnte das durchaus schneller werden.

[Bernhard Geyer]

Zitat:

Zitat von mjustin (Beitrag 1107033)

Also ist SOAP schlanker als das Firebird Protokoll?

Schlanker ist das Protokoll nicht, du wirst es nur so verwenden das die Anzahl der "Ping-Pongs" minimiert wir (Siehe Zitat: "but latency is the main problem as a lot of messages go back and forth"). Schlanker wäre hier z.B. JSON + evtl. Zippen der Datenpackete.

[olaf]

Hallo,

vielen Dank für eure Bemühungen. Sql-Statmentes benutze ich schon. Werde mehr auf dem Client cachen, das habe ich noch nicht so sehr beachtet.

olaf

[QuickAndDirty]

Zitat:

Zitat von olaf (Beitrag 1107073)

Hallo,

vielen Dank für eure Bemühungen. Sql-Statmentes benutze ich schon. Werde mehr auf dem Client cachen, das habe ich noch nicht so sehr beachtet.

olaf

Sowas musst du auch Verwalten !!! Ein Cachen birgt Risiken bei Tabellen die gelesen und geschrieben werden...
Mindestanforderung ist eine Tabelle die die Aktualität der einzelnen Tabellen verwaltet und das muss Multiuser sicher sein.

In kleinen Firmen kann es wesentlich billiger sein das Netzwerk zu verbessern als die Entwicklungsarbeit an kosten verursacht. In großen Firmen ist es sowieso besser sich um einen solchen Flaschenhals zu kümmern...