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.

[Frickler]

Zitat von hoika:

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).

So ein Tool suche ich auch noch. Der SQL-Monitor von DevArt ist leider auf einem Auge blind, wenn es um von IBDAC generierten SQL-Code wie beim IBCLoader oder Array-DML geht.

[tsteinmaurer]

Zitat:

So ein Tool suche ich auch noch. Der SQL-Monitor von DevArt ist leider auf einem Auge blind, wenn es um von IBDAC generierten SQL-Code wie beim IBCLoader oder Array-DML geht.

Falls es über die Firebird Trace API sein darf (benötigt Firebird 2.5 oder höher), dann z.B.: https://www.upscene.com/fb_tracemanager/

IBExpert hat auch eine Firebird Trace API Integration: https://www.ibexpert.net/ibe/pmwiki.....TraceAndAudit

[Frickler]

Zitat von tsteinmaurer:

Zitat:

So ein Tool suche ich auch noch. Der SQL-Monitor von DevArt ist leider auf einem Auge blind, wenn es um von IBDAC generierten SQL-Code wie beim IBCLoader oder Array-DML geht.

Falls es über die Firebird Trace API sein darf (benötigt Firebird 2.5 oder höher), dann z.B.: https://www.upscene.com/fb_tracemanager/

IBExpert hat auch eine Firebird Trace API Integration: https://www.ibexpert.net/ibe/pmwiki.....TraceAndAudit

Der IBExpert zeigt dabei BLOB (Sub Typ 1 = Text) nicht an (statt dessen nur eine Nummer). Ist das eine Begrenzung vom Trace API oder von IBExpert?

[mkinzler]

Dabei handelt es sich um die BLOBID. Die eigentlichen Daten werden ja getrennt von der Tabelle gespeichert.