Fragen bezüglich Performance von Firebird in einer Anwendung

[tsteinmaurer]

Es ist schon unglaublich was man in 2019 versucht mit serverseitiger Hardware zu erschlagen, ohne eigentlich vorher ermittelt zu haben, wo der eigentliche Flaschenhals überhaupt ist. Was hätten wir da vor > 10 Jahren gemacht , wo sich die Platten noch gedreht haben und auch da hat es bereits ERP Lösungen mit > 100 Concurrent Usern im Firebird-Umfeld gegeben.

Obwohl Firebird-seitig ein gewisses Tuning z.b. via firebird.conf möglich und natürlich auch sinnvoll ist, liegt das Hauptproblem fast ausschließlich immer in der Clientanwendung. Da Firebird 2.5+ zum Einsatz kommt, könnte man sonst einfach mal die Firebird Trace API verwenden (IBExpert, FB TraceManager ...), um etwaige Top-Hitters in der Respone-Time zu ermitteln.

Das Problem hier ist dann, sollte man was entdeckt haben, dass man wiederum an den Softwarehersteller angewiesen ist, client-seitig etwas zu verbessern, was sich als schwierig herausstellen kann. Habe ich in letzter Zeit öfters erlebt, dass die Kunden der Software Probleme mit Hardware zu erschlagen versuchen, mit nur mäßigem Erfolg.

[Codehunter]

In aller Regel wissen oder ahnen die Entwickler von Clientanwendungen schon, dass ihr Design "optimierungsfähig" ist. So isses bei uns ja auch. Allerdings entstehen manche Krücken auch aus dem komplizierten Zusammenspiel von Kundenwünschen einerseits und den technischen Eigenheiten zugekaufter Komponenten andererseits. Bei uns ist es oft die unglückselige Gemeinschaft des uralten und nicht mehr wirklich gepflegten FIBplus einerseits und den "kopflastigen" Devexpress-Visualisierungskomponenten andererseits.

Letztere kann ich bei meinen Baustellen zum Glück ausknipsen, weil ich nicht visualisieren muss sondern nur eine "Datenpumpe" schreiben muss. Aber ich sehe schon die Probleme im grafischen Teil. Dem Kunden ist das Warum völlig egal, der sieht nur dass manche Dinge quälend langsam gehen. Weil "DB-Pingpong" umso stärker bremst, je schlechter das Netzwerk ist, fällt es dem Vertrieb noch vergleichsweise leicht mit "bei anderen Anwendern gehts doch auch, muss also beim Kunden liegen" zu argumentieren. Da werden manchmal aber auch Einzelplatzinstallationen (DB und Client am selben Rechner) mit Netzwerkinstallationen vergleichen. Äpfel und Birnen...

Ich sehs so, dass wenn man die Clientanwendung "DB-sparsam" designed, man in schlechten Netzwerken gut läuft und in guten Netzwerken noch besser. Tatsächlich aber lassen sich manche Anwendungsfälle nicht wirklich durchoptimieren. Wenn ich 50.000 BLOBs pumpen muss, dann muss ich 50.000 BLOBs pumpen. Da nutzen mir auch die schönsten EXECUTE BLOCKs nichts.

[p80286]

Zitat von Codehunter:

Wenn ich 50.000 BLOBs pumpen muss, dann muss ich 50.000 BLOBs pumpen.

Dagegen ist nichts einzuwenden, aber wenn man nicht muß, und es trotzdem tut... Und noch schlimmer wenn man nicht weiß was man tut.

Gruß
K-H

[mlc42]

Man kann natürlich jeden SQL Server so füttern das er optimale Performance bringt.
In der Praxis , fernab von Benchmarks hat man dann aber andere Zwänge.

z.B.: über Jahrzehnte entwickelte Anwendungen (> 1000000 Zeilen) von BDE Paradox-
zeiten bis zur heutigen SQL Datenbanken evolutionär weiterentwickelt.
Es werden Fremdkomponenten benutzt auf die man kaum Einfluss hat
und natürlich hat man damals den Fehler gemacht auf das RAD Konzept zu setzen mit seinen
ganzen DB Controls. Unsere Software verfügt dann noch über einen selbst enwickelten
C-Compiler mit Zugriff auf die ganzen Datenbankobjekte. D.h. Kunden haben Makros
im Einsatz die mit Tables etc. direkt arbeiten. Das muss alles noch funktionieren.
Man kann da nicht immer alles neu entwckeln. Zumal bei jeder Änderung die Verläßlichkeit
leidet.
Nichts desto trotz haben wir dank AnyDAC (heute FireDAC) alle Hürden gemeistert und unsere
Anwendung in die SQL Welt überführt und sie läuft robust , verläßlich und in der Regel
schnell genug. Allerdings haben wir uns nicht auf einen SQL Server eingeschossen und
können zwischen verschiedenen SQL Servern umschalten. D.h der gleiche Anwendungscode läuft
,nur mit einigen geänderten SQL Abfragen, da wo es halt Serverunterschiede gibt.

Mit so einer realen Anwendung kann man dann sehen, wie unterschiedlich die Server sind.

Firebird

ist gut nutzbar und wird in der Hauptsache von uns eingesetzt wenn die Datenmengen nicht
zu groß werden, also bei kleineren Kunden.

Postgres ist geringfügig schneller,

MSSQL ist 4-10 mal schneller. Da kommt bei den Nutzern die Geschwindigkeitsprobleme haben
immer ein Wow Effekt auf.

Oracle scheint noch etwas schneller zu sein.

Selbstverständlich haben wir versucht auf allen Ebenen die möglichst schnellste Lösung
umzusetzen, passende Indices gesetzt etc. (Firebird Config Änderungen haben nur minimale
Änderungen gebracht).


Wenn man einzelne, optimale SQL´s absetzt tun die Server sich alle nicht viel, wenn das
Design stimmt (Indices etc.). Wo Firebird aber richtig auffällt ist die langsame Verarbeitung
vieler kleiner Querys. Wo Firebird sich für jede noch so kleine Abfrage viel Zeit lässt
sind MSSQL und Oracle bis zu 10 mal schneller. Sehr gut beobachten kann man das an
alten Formularen die heftig von DB-Grids und Masterdetails gebrauch machen. Wenn der Master
20 Details aktualisieren muss, kann man von flottem Scrollen im Grid nicht mehr sprechen.
Bei MSSQL/Oracle geht das so geschmeidig wie zu alten Paradox Tabellenzeiten.

Das bezieht sich nur auf FB 2.5. Die Umstellung auf FB 3 steht noch aus. Mal sehen ob
sich was getan hat.

[jobo]

Interessante Perspektive, wobei - eigentlich kommt Delphi ja mit dem Anspruch daher, DB unabhängig zu sein.
Darf man die Angaben so verstehen, dass sie sich auf identische Hardware beziehen?

Ein Vergleich zwischen FB 2.x und MS SQL, da liegen aber dann technologisch 10 Jahre dazwischen, (plus ein paar Geldscheine natürlich)

Das wäre aus meiner Sicht auch am ehesten ein Kritikpunkt an fb: die Aktualisierungszyklen.

[hoika]

Hallo,

Zitat:

Wo Firebird sich für jede noch so kleine Abfrage viel Zeit lässt
sind MSSQL und Oracle bis zu 10 mal schneller. Sehr gut beobachten kann man das an
alten Formularen die heftig von DB-Grids und Masterdetails gebrauch machen. Wenn der Master
20 Details aktualisieren muss, kann man von flottem Scrollen im Grid nicht mehr sprechen.
Bei MSSQL/Oracle geht das so geschmeidig wie zu alten Paradox Tabellenzeiten.

Trotzdem ich Fan von FB bin, muss ich hier leider "zähneknirschend" zustimmen.
MS-SQL hat einen sehr guten Query-Cache implementiert, der viel SQL-Murks verzeiht.

In FB muss man das zu Fuss programmieren (prepared Queries).
MS-SQL hat das schon eingebaut.
Allerdings cached MS-SQL aber auch übermäßig viel der DB-Daten.
Gib ihm 2 GB RAM und 2 GB Ram sind weg für den Cache.
Da muss man bei FB erst mal in der conf-Datei rumschrauben.

[mlc42]

Bei den Tests ist es immer die gleiche Hardware. Das ist durchgängig auf allen
Kundenservern so und auch auf unseren Rechnern. Übrigens auch mit sehr alten MSSQL
Servern 2008 und früher (z.B.: W2K).

Ich habe bis heute keine FB Config Parameter gefunden die daran ausser mehr als ein paar Prozent
ändern.

Viele kleine Abfragen sind beim FB wirklich ein Problem. Komplexe Abfragen auch auf sehr große
Datenmengen sind dagegen kein Problem.
Wo immer möglich setzen wir ein Query mit großer Datenmenge ein und arbeiten dann mit
Locate. Das ist sehr viel schneller.

Dem Kunden ist letztlich egal wieviel Speicher gebraucht wird oder was der Server macht.
Der sieht nur das wir umschalten auf den MSSQL und es ist drastisch schneller.
Ich bin jedenfalls froh das wir diesen etwas steingen Wege gegangen sind.

[IBExpert]

Die Cache Mechanismen vom MSSQL basieren wie bei vielen Datenbanken auf serverseitiges Caching und auch clientseitiges Caching.

Wer auf Basis von Firebird und seiner Datasource/Dataset Konstruktion das Netzwerkprotokoll durchschaut, wird feststellen, das die Implementation
der meisten Komponenten in Zusammenarbeit mit dem Firebird Client bei jeder dataset.insert/edit/dataset.post und auch bei first, prior, next, last
alle Nachschlagewerte von allen Lookup Datasets ohne Sinn und Verstand nachlädt. Wenn da in einem Lookup halt 10000 Auswahlmöglichkeiten stehen,
werden die so wie vom Programmierer (auch bei Unkenntnis) befohlen komplett nachgeladen.

Ich weiss das einige Clientlib DLLs da mehr oder weniger intelliger den kram lokal cachen und gar nicht erst übers
Netzwerk holen, weil der Server auf Protokollebene sacht, am Result zum vorhin geholt und prepared SQL hat sich nix
geändert, also nimm den gleich kram noch mal, den der Server vorhin gesendet hab und den die Client DLL eh ncoh im Ram
gecached hat . Ob das nun sinnvoll ist bei sehr dynamischen Datenmenge, lass ich mal im Raume stehen, aber
Fakt ist, die Ursache des Unsinns liegt ganz wo anders: Die komplette master/details datasource Implementation ist
kompletter Müll ist. Und daraus könnt Ihr auch schon mal den Rückschluss ziehen, das es keineswegs damit von mir
gemeint ist, das Delphi Applikationen generell scheisse sind, keineswegs, es kommt darauf an, was man wie damit
macht.

Wenn du lookup controls durch edits und buttons ersetzt und bei bedarf den einen Wert, der da angezeigt werden soll, bereits
gejoint vom Server holst und anzeigst, dann muss der gar nichts nachladen.

Wenn der Anwender aber die Auswahl sehen will und den Button klickt, dann kannst du für genau diese Datenmenge immer
noch alles in einem extra SQL holen, was du anbieten möchtest. Und wenn das wie eine Non DB Listbox direkt unter dem
Edit eingeblendet wird, die das Result des Nachschalge SQL auflistet, den Fokus hat und bei Return oder Doppelklick
den Update auf dem Hauptdatensatz macht, so das dessen FK dem gewählten Entspricht und du alle nur für den aktuellen
Datensatz refresht, dann werden aus ein paar hunderttausend übertragenen Datensätzen eben nur einer. Und es hindert
dich keiner daran, alle Inhalte dieser Listbox für dieses Feld auch beim nächsten Auswählen ohne neues Nachladen von der
DB in der jetzt unsichtbaren,aber immer noch instanziierten Listbox vorzuhalten.

Auch wenn viele Delphi Programmierer glauben, das der dblookup kram das so machen würde, NEIN, macht der nicht. Einfach mal Netzwerksniffer
dazwischen packen und dann sieht man was im Endeffekt über den Draht geht. Und wer da gerade Spaß dran hat: Einfach mal im Grid ein Datensatz
der Hauptdatenmenge editieren und dann auf den vorherigen Datensatz gehen (also prior oder cursor up).

Sorgt bei fast allen Grid-Masken dafür, das noch mal der gesamte Klumpatsch im Grid komplett neu gelesen wird, aber erst
mal alle Datensätze bis eof, um dann beim First wieder anzufangen, um den aktuellen zu finden. Und die passenden Lookup
datasets und dblookup fields werden dabei feundlicherweise auch noch mal für jeden navigationsvorgang noch mal komplett
neu nachgeladen. Nur damit Ihr eine grobe Vorstellung davon habt, warum die Performance eurer Anwendung scheisse ist...

Einige Komponenten wie die von devart sind da bei korrekter Benutzung nicht ganz so scheisse, aber die Realität im
Netzwerk zeigt bei meinen Consulting Jobs, das man zwar meint das es nicht so wäre, aber es ist trotzdem oft so wie ich sage.
dblookup datasets zu ersetzen ist auch im Rahmen von evolution einer Software kein Hexenwerk und dblookup controls dann
zu ersetzen ebenfalls nicht. Wenn man aber keine Ahnung hat, was die für einen Scheiss da veranstalten, warum sollte
man da suchen ....

Wenn eben Performance generell scheissegal ist, dann nimmt man eben datasource/dataset mit ohne ende dblookups auf 20 seiten pagecontrol
Dann aber am besten gar nicht erst auf die Idee kommen, mit so einer Anwendung irgendwann mal größere Kunden zu beglücken. Das wird
scheitern, auch bei ganz doller Hardware ....

Wenn die eigentlich erforderlichen Daten durch den lokalen data cache der treiber im ram gehalten wird und nicht komplett nachgeladen wird,
dann mag es so aussehen, als ob die Plattformen 4-10 mal schneller sind, das bezieht sich dann aber nur auf eure Software und eure Implementation

bzgl: eigene erkenntisse: wer firebird benutzt kann ja mal das tool runterladen
https://ibexpert.com/tcp/tcpipe.zip

dann folgendes einstellen und starten

Statusseite:
Remarks=fb
BindIp=127.0.0.1
ListenPort=3051
MapIp=127.0.0.1
MapPort=3050
Map=true
Logging=true
LogDataMode=5

Loggingseite:
LogToScreen=true
ScreenLogLines=50000


und danach eure app mal mit connectionstring 127.0.0.1/3051:aliasoderpfadzurdb statt 127.0.0.1/3050:aliasoderpfadzurdb starten.

Dann steht ihr in fb25 unverschlüsselt, was da bei ganz simplen Operationen über den Draht geht und ich garantier jedem dataset/datasource/lookup kram
benutzer, das ihr da auf der logging seite dinge sehen werdet, die auf keine screen eurer applikation sichtbar sind (weil die nur in lookup optionen
sind, die aber nicht geöffnet sind) und die dann eben bei jedem navigieren der Hauptdatenmenge neu nachgeladen werden. Außerdem zeigt euch das Tool
noch an, wie viele Pakete und Bytes da hin und her gejagt wurden.

Das tool bekommt jeder Teilnehmer bei entsprechenden Schulungen von uns, es gibt auch zig millionen andere ähnliche Tools die das alles noch viel besser
können, bringt aber nix wenn man von 10 möglichen besseren Tools auch noch keines benutzt hat oder deren Ausgabe nicht versteht. Wenn ihr wollt könnt
ihr damit auch andere tcpip protokolle umbiegen und darüber sehen, was auch da über den Draht geht. ist zB auch insbesondere beim verstehen, warum https
besser ist als http nicht ganz uninteressant.

Bei fb3 müsste ihr ggf vorher noch den parameter wirecrypt in der firebird.conf anpassen, sonst werdet ihr da nichts lesenswertes sehen.

[Codehunter]

Zitat von mlc42:

Wo Firebird aber richtig auffällt ist die langsame Verarbeitung
vieler kleiner Querys. Wo Firebird sich für jede noch so kleine Abfrage viel Zeit lässt
sind MSSQL und Oracle bis zu 10 mal schneller.

Diese Erfahrung kann ich bestätigen. Ich kam aus dem Ökosystem von MariaDB, damals 10.2, und war dann mit Firebird 2.5 konfrontiert. Da war ich teilweise entsetzt über die Unterschiede. Natürlich kann man auch umgekehrt argumentieren, dass Firebird 2.5 eine gute Schule für effizientes Programmieren ist. Das Problem was ich sehe ist nur, dass im Praxisbetrieb sehr viel Entwicklungszeit in Umgehungslösungen investiert werden muss. Für Performancetests muss man auch noch Benchmarks am eigenen Datenmodell entwickeln. Viel Aufwand. Das verkneift sich ein Unternehmen gerne, weil die Fortschritte kaum an Lastenheften gemessen werden können.