Geschwindigkeit Firebird über Netzwerk

[Olli73]

Hallo!

wenn unser Programm über "localhost" auf eine Firebird-Datenbank auf dem gleichen Rechner zugreift, ist alles ausreichend schnell. Liegt die Datenbank auf einem Server ist es deutlich langsamer.

Mir ist nun aufgefallen, dass die Netzwerkverbindung weniger als 10 MBit in der Spitze nutzt. Es ist ein Gigabit-Netzwerk und wenn ich Dateien kopiere, komme ich auf 200 bis 600 MBit.

Kann ich da etwas tun?

Achso: Die DB ist Firebird 3.0 64 bit und das Programm ist 32 bit.

[Sinspin]

Zum entwickeln nie mit einer lokalen Testdatenbank arbeiten. Sondern immer übers Netzwerk zugreifen. So vermeidet man schon von Anfang an Schweinereien die einem später Probleme machen.

Datenbank seitig, die verwendeten Übertragungeinstellungen prüfen. Client seitig Rowset Größe, lokale Pufferung, Verschlüsselung, Kompression.
Wenn es sich anfühlt als wenn die Clientseite nicht richtig saugt, sind das in der Regel datensensitive Komponenten die beim Laden der Records aktiv sind und die ganze Zeit aktualisieren. DevExpress TcxGrid zum Beispiel!

[himitsu]

Zitat:

Zum entwickeln nie ...

Oder ein Network-Throttling einrichten, also die Verbindung künstlich ausbremsen.

[Olli73]

Danke für die Antworten.

Das ist ein uraltes Programm, was wir von der BDE auf Firebird migriert haben; natürlich ist da nicht alles optimal programmiert für einen SQL-Server. :(

Aber der Flaschenhals scheint ja zu sein, dass von 1000 MBit nur Maximal 10 verwendet werden. Würde er wenigstens 50 oder 100 verwenden, wäre es wahrscheinlich super schnell.

Also wäre meine Frage erstmal, warum das Netzwerk hier mit 4 bis 10 MBit arbeitet?

[himitsu]

Die 1000 schaffst'e auch nur, wenn durchgehend größere Blöcke übertragen werden.
Mit ganz vielen winzigen Datenschnipseln und vielleicht noch schlechtes Caching und Sonstiges im Programm dazwischen, schon bricht das extrem ein.

Bestes Beispiel für Derartiges ist der Unstoppable Copier.
Läuft das Drecksding in einen Fehler, wird Byteweise gelesen, was aber totaler Schwachsinn ist, da nur sektorweise Zugriffe möglich sind. ist also der Sektor kaputt, wird tausende Male auf die kaputte Stelle zugegriffen, jedesmal dann auf Fehlerbehandlung und/oder den Timeout warten und auch noch die Platte extrem stessen, da unnötig zu oft auf der kaputten Stelle rumgehackt wird.

Selbst wenn dann irgendwann wieder etwas Ganzes kommt, wird weiterhin ein Weilchen so gearbeitet, auch wenn dann der Cache des OS greift, wird immer wieder der Sektor kopiert, ein Byte rausgeholt, der Rest verworfen und das Ganze dann erneut für die nachfolgenden Bytes. :freak:

[Delphi.Narium]

Die BDE ist 'ne Datenbankschnittstelle. Firebird 'ne Datenbank.

Wie greift ihr auf die Datenbank zu?

Weiter per BDE (TTable, TQuery)? Über ADO? Über ODBC? Über die Zeos-Komponenten, FireDac, DevExpress, ...?

Jenachdem könnte es durchaus unterschiedliche Flaschenhälse geben, die für die Langsamkeit verantwortlich sein könnten.

Ist nur euer Programm so langsam oder ein Zugriff mit einer anderen Datenbanköberfläche (wie z. B. FlameRobin) auch?

Was genau ist mit

Zitat:

Das ist ein uraltes Programm, was wir von der BDE auf Firebird migriert haben;

gemeint?

Wenn ich in der BDE-Konfiguration im Alias die Datenbank ändere, kann ich letztlich in 2 Minuten (oder so) 'ne Software von z. B. DBase auf FireBird, Oracle, ... umstellen. Solange die Tabellendefinitionen passen und keine exotischen Besonderheiten im SQL verwendet werden, sollte das (meist problemlos - wenn auch suboptimal) klappen.

Hier könnten zusätzliche Infos, zur Art der Umstellung ..., bei der Suche nach dem Flaschenhals hilfreich sein.

[IBExpert]

wie ist denn deine ping zeit vom client zum server? mit einem tool wie www.ibexpert.com/tcp kannst du dir ein proxy in den firebird tcpip traffic einrichten und sehen was der da so macht, hatte ich in einem der stammtisch videos auf youtube auch mal gezeigt.

ist bei altsoftware meistens aber extrem gruselig und alles was da an datasets beteiligt ist macht es noch schlimmer, und wenn blob spalten dazu kommen erst recht.

Wenn du dataset aufmachst auf einer tabelle mit 1000 records und 20 spalten von denen 2 blobspalten sind, hast du auf jeden fall schon mal geschätzt 4000 tcpip pakete, von denen jedes deine ping zeit verbraten wird. im local network mit <1ms meistens egal, remote aber gar nicht.

das kann man nur durch eine dafür passende architektur vermeiden und bevor die üblichen vorschläge kommen mit middleware dazwischen, klar, braucht man aber nicht als extra zwischenschicht, die man ja auch neu entwickeln müsste, wenn man gleich die abfragen an firebird passend baut (zB ein sql als blob senden in dem drin steht was der server machen soll und als result zum beispiel ein blob kommt, in dem alles vom ergebnis in passenden formaten ist (ob das json/xml/csv oder sonstwas ist ist egal), das der programmierer beherrscht und wieder lokal in sein dataset oder sonstwohin lädt.

bei einer altsoftware würde ich als einzige lösung zur kompletten neuentwicklung nur den terminalserver betrieb im netz vom server als einzige machbare alternative sehen. entscheidend ist die ping zeit vom client zum server, bandbreite ist sekundär.

[Olli73]

Oben steht "Zugriff über FireDAC". ;)

Wir haben das schon alles umgestellt, leider sind noch viele (TFD)Table-Komponenten vorhanden. Aber da haben wir die Performance dadurch verbessert, dass wir für kleine Tabellen Client- und für große Tabellen Server-Cursor verwenden.

[Olli73]

@IBExpert:

Danke. Den Ping und das Tool werde ich am Montag Mal testen.

In der Tat sind schon viele Kunden auf RDP (wir bieten das u.a. auch in unserem Rechenzentrum an) umgestiegen...

Und wir sind auch dabei einen Rest-Server zu implementieren, der kann aber noch nicht so viel.

[hoika]

Hallo,
ich hätte da noch das hier:
https://docwiki.embarcadero.com/RADS...chung_(FireDAC)

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

Zitat von Olli73 (Beitrag 1530456)

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:

Zitat von lxo (Beitrag 1530469)

Zitat:

Zitat von Olli73 (Beitrag 1530456)

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.

[Olli73]

Wenn ich die Verschlüsselung abschalte, wird dann auch das Passwort unverschlüsselt übertragen?

Oder ist das ein eigenes Protokoll:

https://firebirdsql.org/file/documen...ntication.html

Zitat:

Firebird 3 has new method of user authentication implemented as a default plugin: secure remote password (SRP) protocol.

[IBExpert]

das password wurde bei firebird noch nie im klartext übertragen, nur ein unidirektionaler hashwert davon, den der server dann vergleichen kann mit dem was der für das passowrd hält, daher ist der part unkritisch, war auch schon bei älteren firebird versionen so.

[Olli73]

Zitat:

Zitat von IBExpert (Beitrag 1530519)

das password wurde bei firebird noch nie im klartext übertragen, nur ein unidirektionaler hashwert davon, den der server dann vergleichen kann mit dem was der für das passowrd hält, daher ist der part unkritisch, war auch schon bei älteren firebird versionen so.

Danke!