Fragen bezüglich Performance von Firebird in einer Anwendung

[TK8782]

Guten Tag,

ich bin neu hier im Forum und möchte zunächst mal alle Experten hier begrüßen.

Ich habe nun aktuell bereits eine Frage, die mich seit einiger Zeit beschäftigt.

Wir nutzen intern eine Businesssoftware (ERP) die im Hintergrund eine Firebird 2.5 bzw. Firebird 3.0 Datenbank verwendet.
Da wir die Performance der Anwendung verbessern wollten, haben wir den bestehenden Server auf dem die Firebird Datenbank bisher lief aktualisiert.
Der alte Server hatte folgende Hardware:

Intel XEON E5-2630 v4 2.10 GHz
64 GB RAM
HP SSD Drive für die Datenbank mit folgenden Werten:
RANDOM READS : 64000 IOPS
RANDOM WRITES : 26000 IOPS
SEQUENTIAL READS : 535 MBPS
SEQUENTIAL WRITES : 380 MBPS
Gigabit Netzwerkkarte

Um mehr Performance zu erhalten haben wir den Server ersetzt und anstelle einer normalen SSD die Datenbank auf eine NVMe Festplatte gelegt.

Der neue Server hat folgende Daten:
Intel XEON Silver 4215 2.5GHz
32 GB RAM (hier wurde weniger verwendet, da der RAM sowieso nie voll belegt war)
Intel DC P4510 NVMe Drive mit folgenden Werten:
Sequenzielle Lesezugriffe (bis zu) 3200 MB/s
Sequenzielle Schreibzugriffe (bis zu) 2000 MB/s
Zufällige Lesezugriffe (Bereich: 100 %) 637000 IOPS
Zufällige Schreibzugriffe (Bereich: 100 %) 81500 IOPS
Gigabit Netzwerkkarte

Beide Server sind am selben Netzwerkswitch angeschlossen und nicht virtualisiert.

Nachdem die Datenbank umgezogen war, habe ich entsprechende Performancetests ausgeführt.
Wenn ich z.B. den Test von IB-AID https://ib-aid.com/en/simple-insert-upd ... -firebird/ ausführe, dann ist mein neuer Server auch deutlich schneller als der alte.

Leider, und das ist das Problem, merken wir das in der Anwendung nicht. Diese ist, wenn überhaupt, nur minimal schneller.
Ich vermute ja dass es an der Anwendung liegt. Daher habe ich parallel zur Arbeit in der Anwendung mal einen Test mit procmon durchgeführt und die Log-Datei von procmon überprüft.
Es ist auffällig dass sehr viele TCP-Requests bei Aufruf von DAtensätzen in der Anwendung stattfinden. Ist das für Anwendungen, die Firebird als Datenbank verwenden normal oder liegt dies in der Art und Weise der Programmierung?
Da innerhalb der Datenbank relativ wenig mit StoredProcedures, Triggern etc. gearbeitet wird und die SQLs rein aus der Anwendung heraus passieren, stellt sich mir in der IT die Frage ob ich durch bessere Hardware überhaupt noch Geschwindigkeitsverbesserungen in der Anwendung erreichen kann.

Hat hier jemand Erfahrung oder ähnliches schon erlebt?

Vielen Dank.

[hoika]

Hallo,

Zitat:

Es ist auffällig dass sehr viele TCP-Requests bei Aufruf von DAtensätzen in der Anwendung stattfinden. Ist das für Anwendungen, die Firebird als Datenbank verwenden normal oder liegt dies in der Art und Weise der Programmierung?

Kommt drauf an.
Hier kann nur der Entwickler des Programmes eine Antwort geben.

Es gab mal bei HK Software einen DB-Monitor,
wo man die einzelnen SQL-Befehle protokollieren konnte,
ohne das es die eigentliche Anwendung mitbekommt ...
Ich finde den Monitor aber nicht mehr (habe den damals sogar selber gekauft).

Firebird ist eine sehr performante Datenbank, die aber durch "etwas unglückliche" Programmierung auch ausgebremst werden kann.
Da halte ich mich aber raus. "Programmierer-Ehre" .


Man könnte am DB-Cache etwas drehen.
Firebird benutzt pro DB standardmäßig relativ wenig Cache.

https://firebirdsql.org/manual/gfix-buffers.html

Zitat:

Da innerhalb der Datenbank relativ wenig mit StoredProcedures, Triggern etc. gearbeitet wird und die SQLs rein aus der Anwendung heraus passieren, stellt sich mir in der IT die Frage ob ich durch bessere Hardware überhaupt noch Geschwindigkeitsverbesserungen in der Anwendung erreichen kann.

Hier muss man sich einfach mal mit der Entwicklerfirma zusammensetzen.

[Codehunter]

Da passt das hier ganz gut ins Bild. Firebird ist in puncto SQL doch recht beschränkt. Wenn Entwickler Erfahrung in Mysql oder Oracle haben, müssen sie gewaltig umdenken, sonst endet es genau bei den von dir beschriebenen Problemen. Für gute Performance muss man bei FB etwas tun, was eigentlich immer gelehrt wird nicht zu tun: Möglichst große Abfragen machen, lokal vorhalten und dort durchsuchen. Nur wird genau das bei Updates kontakariert, weil FB kein Multi-Row-Insert/Update beherrscht und man sich solcher Krücken wie Execute Blocks bedienen muss. Von FB 2.5 auf 3.0 wurde es etwas besser, nur nützt einem das nix wenn die Anwendung für 2.5 entwickelt wurde und die Abfragen entsprechend aufgebaut sind. Dann läuft FB3 sozusagen im Kompatibilitätsmodus und die Performance ist praktisch identisch.

Mit anderen Worten: Die investition in einen Ferrari als Ersatz für den Mercedes SLK war vergeblich, weil die Straße eine Schlaglochpiste ist.

[jobo]

Ich würde das etwas differenzieren.

Hardware
Einfache Rechenbeispiele: Wenn ich eine quad core CPU gegen eine octa core austausche, wie viel schneller wird dann mein Programm (unter Idealbedingungen)? Doppelt so schnell. Umgerechnet auf Wartezeiten: Aus 10 Sekunden Warten, werden 5 Sekunden.
Das kann man für alle Hardwarebestandteile durchexerzieren. Die Rechnung ist immer die gleiche.

Software
Algorithmen können gut oder schlecht, passend oder unpassend sein. Das gilt für SQL, für Floating Point Arithmetik aber auch für Units und Komponenten (in Delphi). Optimierungen sind hier oft viel weitreichender möglich und bringen Faktoren, die Du mit (bezahlbarer) Hardware nicht ohne weiteres erreichen kannst.

Also ja, man muss sich die Anwendung anschauen. Auch wenn Du es nicht beschrieben hast, Du wirst wissen, wo der Schuh drückt. Eine generelle Sache oder bestimmte "unangenehme" Ecken der Anwendung...
Bei einer Client Server Anwendung spielen natürlich auch Netztopologie und Auslastung, -Konfiguration eine Rolle.
Ich hatte noch nie den Bedarf eine Delphianwendung an den Paketscanner zu hängen, aber ja, sie arbeitet (im Datenbankverkehr) vollkommen anders als eine Webanwendung. Es wird viel hin und her geschickt. "Früher" war die Herausforderung, eine Anwendung notfalls über ISDN laufen zu lassen. Klingt vielleicht bescheuert, aber es geht und in solche Richtungen muss man immer denken, wenn man evtl. unbekannte/fremde Komponenten einsetzt oder ein koplexes Datenmodell anlegt bzw. abfragt. Was auf dem Entwicklerrechner geht, ist in der "Wildbahn", also z.B. Firmennetz mit 100en Clients und "Konkurrenzprogrammen" dann halt doch was anderes.

Anwendung
Oft sind es einfach noch relikte aus BDE Zeiten. Da wurden Tabellen einfach geöffnet. Geht anfangs immer prima, wenn sie so gut wie leer sind. Aber das bleibt ja im Normalfall nicht so. Auch wenn sich nur ein paar Tausend Datensätze ansammeln, das kann man hochrechnen mit der Anzahl der Clients. Jedes Schließen/Öffnen zieht dann eben immer wieder ein paar Tausend Datensätze.
Auch wenn man einen SQL Server einsetzt, bedeutet das nicht, dass SQL als Abfragesprache zweckmäßig und Ressourcen schonend eingesetzt wird.


P.S.:
Datenbank
Es ist sicher hilfreich, die aktuellste Version einzusetzen (Stichwort Sprachfeatures). Um die dann zu nutzen, muss man natürlich trotzdem an die Anwendung ran. Außerdem ist es so, dass natürlich der Hauptspeicher als Buffer eingesetzt werden sollte, soweit wie möglich (wenn nicht ständig nur Updates gefahren werden und nie ein Stein auf dem anderen bleibt)
Bei heutigen RAM Ausstattungen ist die DB ja manchmal kleiner als der Hauptspeicher. Hat man in der Konstellation Performance Probleme, würd ich eher auf Netzauslastung bzw. unnötige (unnötig große,~undifferenzierte) Datenabfrage tippen.

[Codehunter]

Ich sage ja auch nicht, dass FB per se langsam ist. Nur braucht es spezielle Erfahrungen, die Möglichkeiten, auch im Zusammenspiel mit Delphi, richtig zu nutzen. Kommt man als Entwickler von anderen relationalen DBMS, dann kann man sich schnell verrennen. Ich sprech da aus Erfahrung

Der Hinweis vom Erstpost mit den vielen Verbindungen deutet auf ein spezifisches Designproblem bei der Clientanwendung hin. Dass es nur wenige Storedprocs gibt, bestätigt die These ein Stück weit. Insofern müsste der Anwender eher die Clients aufrüsten als die Server. Hier würde mir mein Bauchgefühl eher zu hochtaktenden 2-Kernern raten als zu Multicores. Schließlich sind (ältere) Delphi-Anwendungen in aller Regel immer noch Singlethread-Programme. Auch die Netzwerkstrecke müsste man sich anschauen. Switch ist nicht gleich Switch, es gibt große Unterschiede bei deren Performance.

Aber bei aller Müh werden sich die so erzielbaren Verbesserungen in Grenzen halten. Ohne Optimierung der Anwendung würde ich sagen: Wirtschaftliche Sackgasse.

[jobo]

Zitat von Codehunter:

Ich sage ja auch nicht, dass FB per se langsam ist.

Darauf wollte ich auch gar nicht hinaus. Es gibt natürlich Performance Vergleiche unter den führenden DB Anbietern, aber ich glaube, da ist erstmal ziemlich viel Pulverdampf dabei.
Vielleicht mal so rum: Ich kann auch MSSQL oder Oracle DB ungünstig einsetzen.

Und noch ein Nachtrag:
Datenbank Tuning durch einen Fachmann kann in der Situation schon hilfreich sein. Es kommt halt drauf an.
Wenn die Anwendung immer recht große Joins macht oder große Sorts, deren Volumen blöder Weise immer über der definierten Speichergrenze für JOIN oder SORT liegt, dann geschieht das immer auf Platte statt dass der Server "Kopfrechnen" (so nenne ich das immer) machen kann. Es werden also buchstäblich die (Zwischen-)Ergebnisdatensätze auf der Platte nebeneinander gelegt und sortiert..

Sollte bei einer Highend SSD auch kein Problem sein, ist wieder ein Frage der Frequenz/ Gesamtdurchsatz/ Nutzerzahl.
Erste Ansätze liefert da aber auch schon ein Blick auf die Last der Platten. Oder einfach mal nach Betriebsschluss mit einem Client Standardvorgänge durchgehen und die Serverlast protokollieren.

Aber diese Hinweise werden schon zu spekulativ. Da könnte der TE mal ein paar weitere Fakten nennen. DB Größe, Tabellenanzahl, Datenvolumen in den Tabellen, also Anzahl Records, Datentypen (manchmal werden ja ganze Filme in Datenbanken gspeichert), Anzahl Nutzer, konkrete Performance-Engpässe usw.

[Codehunter]

Zitat von jobo:

Datenbank Tuning durch einen Fachmann kann in der Situation schon hilfreich sein. Es kommt halt drauf an.

Richtig. Da muss man sich immer den Einzelfall anschauen. Ich wäre jedenfalls sehr daran interessiert, sollte durch Einstellungen am DB-Server das beschriebene Problembild sich wesentlich verbessern. Denn die Problemlage ist mir bei unserer DB sehr vertraut.

[TK8782]

Hallo zusammen,

ich danke euch zunächst mal für Eure Einschätzung, die in gewisser Weise das bestätigt was ich unseren Entwicklern bzw. GL bereits mitgeteilt habe und was auch mein Verdacht ist.
Man muss sich die Anwendung und die Art und Weise wie diese programmiert ist anschauen. Es handelt sich um eine Anwendung, die noch vor Kurzem via BDE angesteuert wurde und die Client-Server basiert ist, d.h. die EXE liegt zwar auf einem Fileshare im Netzwerk, wird aber lokal auf den Rechnern über eine Verknüpfung aufgerufen. Danach stellt die Anwendung eine Verbindung zur Firebird-Datenbank her.

Ich persönlich bin mit meinem Latein was Optimierung betrifft mittlerweile am Ende angelangt, da ich auch bereits die verschiedensten firebird.conf Konfigurationen gefahren bin mit unterschiedlichsten Einstellungen hinsichtlich Cache usw. Hier gibt es ja verschiedenste Hinweise im Internet bzw. vorgefertigte Konfigurationsdateien, die man ausprobieren kann. Wirklich schneller wird es dadurch aber nicht!

Da am Server selbst auch die gesamten Ressourcen wie CPU, RAM, Netzwerk, Festplatte mit einer minimalen Auslastung laufen, auch wenn größere Abfragen abgesetzt werden vermute ich das Bottleneck eher in der Netzwerkanbindung von Client zu Server, wobei wir hier auch durchgängig Gigabit-Anbindung mit HP-Switchen haben (Cisco wäre zwar besser, aber für die Geschwindigkeit der Anwendung sollte das nicht den wesentlichen Unterschied machen) bzw. das Bottleneck ist doch in der Anwendung zu suchen.

Für weitere Diskussionen bin ich jederzeit offen!

Grüße

T

[jobo]

Also wenn der Server überhaupt keine Last zeigt, dann ist da doch irgendwas anderes im Busch.
Sind das echte Clients? Citrix?..
Funktioniert die Namensauflösung bzw. das Routing vom Client sauber zum DB Server? Wenn z.B. jedes Paket erst mal beim lieben Gott fragen muss, wo es hin soll und wie es wieder zurück kommt, dauert das in Summe auch.

[TigerLilly]

In deiner Situation können diese Bereiche das Problem darstellen:
- der Server
- das Netzwerk
- der Client
- die Software selbst

Server und Netzwerk hast du schon ausgeschlossen. Dann schau dir den Client an. Ist der manchmal sehr unter Last? Wenn ja, was ist die Ursache? CPU? Platte? Wann ist das + was wird in der Software dann gemacht? Versuche, die Stellen in der SW zu identifizieren, an denen es hängt.

Wie andere auch schon gesagt haben: Binde den Hersteller der Software ein.

Ich hatte mal eine SW, die hat in regelmäßigen Abständen (1s) nachgesehen, ob es ein Update im Server gibt. War bei 2/3 Clients kein Problem. Bei 200 war das dann nicht mehr lustig.