Geschwindigkeit Firebird über Netzwerk

[QuickAndDirty]

Bei Firebird sind die Laufzeiten "ping-pong" im Netzwerk sehr wichtig.
Man kann das ein bisschen verbessern, wenn man die Queries fetched und generel vorrausschauend größere Datenmengen anfordert, statt viele male kleine passende Datenmengen.
Firebird wird niemals so schnell sein wie Paradox!!!
Dafür wird es auch nicht so oft kaputt gehen we Paradox im Multi-Userbetrieb.

[IBExpert]

Paradox und schnell? nun denn, jeder macht da seine eigenen erfahrungen.

schon mal eine paradox db auf einem nas mit 100mio records benutzt? vermutlich eher nicht, weil dadurch im prinzip unbenutzbar.
ist dann nämlich bei paradox über das netzwerk nix anderes, nur das sich ggf noch ein filesystem cache da reinhängt, der aber
dann im gegensatz zu fb auch den gesamten inhalt an den client übertragen muss und nicht wie fb nur den result.
Und ganz nebenbei belegt paradox für eine tabelle mit 1000 records und 10 varchar(100) feldern auch immer mindestens 100000 bytes
nur für die daten, egal ob da was drin steht der nicht. Firebird benutzt dafür ein wesentlich effektiveres Dateiformat
speichert solche daten im prinzip nur null terminiert (technisch ist das zwar ein wenig komplizierter weil auch ein leerer
varchar(32000) ca 500byte belegt, aber eben nicht 320000 byte).

Paradox Single user betrieb lokal mach das ja noch ganz nett sein, aber im netzwerk mit mehreren usern, die gleichzeitig lesen und
schreiben wollen, viel spass damit ....

das die da dauernd kaputt geht sagtest du ja schon.

Bzgl caching: was man mit dem tcp tool ganz gut sieht, der firebird client fetched vom netzwerk auch schon daten, die ggf noch gar nicht in einem dbgrid sichtbar sind und füllt damit tcpip pakete schon selber vorausschauend auf, so das zum beispiel immer 16k oder 32k gut gefüllt übergeben werden (sieht man per default aber nur bei fb <= 25 weil ab fb over the wire encryption die paketinhalte nicht so gut lesbar machen, kann man da in der conf aber auch abstellen.

[Olli73]

Also das mit den BLOBS war ein guter Hinweis. Die Zeit zum holen von 2500 Records mit 66 Feldern inklusive 1 Blobfeld (edit: das Blobfeld war leer!) über Netzwerk konnte so von 4 auf < 0,5 Sekunden verbessert werden. Das bringt schon mal an ein paar Stellen einen Vorteil.

Ich habe einfach bei den Fetch-Options von FireDAC bei der Eigenschaft Items das "fiBlobs" rausgenommen.

Des weiteren habe ich ein paar Tests mit verschiedenen Datenbanken gemacht. Fazit meiner Tests: MSSQL ist (zumindest bei großen Datenmengen übers Netzwerk) fast doppelt so schnell wie Firebird. Dafür ist aber wiederum Firebird doppelt so schnell wie Maria DB. MSSQL und MariaDB benötigen aber auf dem Client deutlich mehr Speicher, musste für meine Tests sogar auf 64 bit umstellen.

[Olli73]

Zu Paradox / DBase: in unserem Fall war das schneller übers Netzwerk (und Multiuser), "Dateien" werden aber auch wohl mit bis zu 600 MBit "gesaugt".

Von daher sind unsere Kunden halt verwöhnt, was die Geschwindigkeit angeht.

[Olli73]

Neue Erkenntnis:

Ich habe am Server die Verschlüsselung über TCP abgestellt und die Paketgröße vervierfacht. Das hat bei großen Tabellen 20 % gebracht, aber bei kleinen Abfragen den Speed vervierfacht bis verfünffacht.

[lxo]

Zitat von Olli73:

Neue Erkenntnis:

Ich habe am Server die Verschlüsselung über TCP abgestellt und die Paketgröße vervierfacht. Das hat bei großen Tabellen 20 % gebracht, aber bei kleinen Abfragen den Speed vervierfacht bis verfünffacht.

Wo hast du das eingestellt? Firebird oder Betriebssystem?

[Olli73]

Zitat von lxo:

Zitat von Olli73:

Neue Erkenntnis:

Ich habe am Server die Verschlüsselung über TCP abgestellt und die Paketgröße vervierfacht. Das hat bei großen Tabellen 20 % gebracht, aber bei kleinen Abfragen den Speed vervierfacht bis verfünffacht.

Wo hast du das eingestellt? Firebird oder Betriebssystem?

In der Firebird.conf Datei.

WireCrypt = Disabled
TcpRemoteBufferSize = 32767

[lxo]

@IBExpert

Zitat:

TcpRemoteBufferSize = 32767

Kannst du was dazu sagen?
Irgendwelche Erfahrungsberichte bzw. Empfehlungen für diese Einstellung?

[MEissing]

https://firebird-devel.narkive.com/u...motebuffersize

[IBExpert]

ich kann mich noch dunkel an ein projekt erinnern, bei der wir mit firebird über relativ lahme handy verbindungen arbeiten mussten, dort kannte man wirklich jedes byte beim namen und mit bedeutung, so das wir da, weil immer nur möglichst keine datenpakete gesendet und geholt werden sollten, um den overhead so gering wie möglich zu halten, das mal auf den minimalen Wert eingestellt. Der effekt war nicht so wirklich doll, weil wenn man immer irgendwas mit ca 100 byte liest und schreibt, macht der die pakete eh nicht größer als erforderlich.

Beim fetch für ein resultset (ohne blobs) wird da aber sicherlich schon ein positiver unterschied sein, wenn die pakete groß sind, aber der unterschied zwischen 8k und 32k hält sich da auch in grenzen, ist aber ziemlich sicher auch nicht immer 8k.

ich weiss ganz sicher (unter anderem auch durch benuzung vom tcpip expert, siehe screenshot mit einer fb4 installation, an der ich de fakto keine änderungen an dem parameter gemacht habe), das die paketlänge in tcpip netzwerk immer alle möglichen länge zwischen ein paar bytes und 32k sind, auch wenn man da nix einstellt (das der kram im screenshot nicht lesbar ist liegt an wirecrypt aktiv, was aber ja immer leistung frisst, insbesondere auf langsamen cpus, so das man da in eh geschützten Netzwerken auch ohne schlechtes gewissen abschalten kann). das da sictbare paket kam bei einem execute and fetch all befehl von ibexpert auf eine tabelle mit 100000 records, also weit mehr als in ein paket passen könnte.

Wenn der client daten anfordert und der server 32k an daten oder mehr liefern könnte macht der das auch, egal ob der client die zB in einem dbgrid schon anzeigen will oder kann. dadurch sieht man im tcpipe bei grids manchmal seltsame effekte. Man hat die erste 100 records geholt, sah aber im Datenpaket schon records 1-200. wnen man im grid nu auf record 101 geht holt sich der firebird client von den komponenten veranlasst ein wieteres datenpaket, so das nun zum Beispiel 201-400 kommen, auch wenn der im Grid noch bei 101 ist usw. bei 201 kommt dann manchmal schon 401-600 usw ...

deshalb auf langsamen verbindungen immer mit select first 100 ..... o.ä. arbeiten, weil dann nur das über das netz geht, was in der menge ist. lokaler filter ist dann offensichtlich kompletter mumpitz.