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)