Fragen bezüglich Performance von Firebird in einer Anwendung

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

[Codehunter]

Zitat:

Zitat von mlc42 (Beitrag 1441024)

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.

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

[Codehunter]

Ich würde ja gerne mal FB 4.0 ausprobieren. Weil wir aber FIBplus verwenden, ist uns dieser Weg versperrt. Es gab mal den Plan, eine Art Abstraktion auf FireDAC drauf zu setzen, die FIBplus "emuliert". Aber damit ist es ja nicht getan. Man muss schrottige Queries und Procedures anfassen. Denn selbst wenn man die rein technische Konnektivität hin bekäme, würden wohl die Vorteile von FB 4.0 verpuffen.

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

[hoika]

Hallo,
ich hatte ja gesagt -> FB-Fan.

Dabei bleibt es auch.
Unsere App hat bei den meisten Queries handoptimierten Code,
und wenn nicht, klappt das auch so.
Sonst würden wir das ändern...

Multi-DB- > kein Grund, viel zu aufwendig im Support.

[tsteinmaurer]

Holger,

sehr gute Punkte, ich bin da voll bei dir und jeder der mit Softwareentwicklung zu tun hat, kann und soll sich ruhig auch mal auf die Netzwerkebene begeben. Entweder mit deiner Proxy-App, Wireshark etc. Delphi Clientbibliotheken (IBObjects, IBDAC, ...) bieten auch oft selbst eine Art "SQL Monitor" Komponente an, die sehr interessante Einblicke gibt, was denn da so ausgeführt wird. So auch die Firebird Trace API, aber alles halt nicht auf Netzwerkpaket-Ebene. Was aber die Trace API z.b. bietet ist die Anzahl der zurückgegeben Rows einer ausgeführten SQL Abfrage.

Delphi hat RAD (Rapid Application Development) vor vielen, vielen Jahren geprägt und eben Konzepte wie datensensitive Komponenten etc. eingeführt, aber zu Beginn halt auch sehr stark auf lokale dateibasierten Datenbanken ausgerichtet, wo viele dieser "Probleme" nicht auftauchten. Da war es egal, wenn eine datensensitive Lookup-Komponente mehr im Hintergrund macht, als man glaubt, z.b. alle Daten "lokal" rüberholen und dann das Locate darauf ausführen. Fürs Netzwerk und PingPong zwischen Client und Server nicht wirklich hilfreich.

[mlc42]

Zitat:

Zitat von IBExpert (Beitrag 1441045)

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

Nur bei Firebird. Wir haben Kunden mit Datenbanken im GB Bereich auch ohne besonders dolle Hardware. Mit MSSQL oder Oracle klappt das hervorragend,
da stockt nichts beim scrollen auch wenn man zig Master/Detail auf einem Formular hat. Da kann man nicht davon reden das es so scheint als
wenn der SQL Server schneller ist. Er ist sehr viel schneller. Irgendwas machen die anderen da wohl bedeutend anders, ich würde sogar sagen besser, als Firebird.
Das ist schade weil ich Firebird ansonsten sehr gut finde. Schön schlank, einfach zu installieren, läuft auch auf Linux.
Könnten wir die Anwendung und alle Tools selbst mal eben neu schreiben, würden wir das aus heutiger Sicht wohl anders aufbauen.

[IBExpert]

Ich bleib dabei, das das Problem nur mit Delphi Applikationen mit dieser grauenhaften datasource/dataset/lookup
Konstruktion auftaucht und warum andere das dafür ggf besser machen, hab ich ja oben schon mal geschildert.

Wir haben bei Kunden Firebird Datenbanken mit mehr als 2TB, oder eben auch mit ca 400GB und täglich 2,5 Millionen neuer
Datensätze, die 180 andere Server per direkter Verbindung via ssh Tunnel von diversen Standorten quer durch Deutschland
da jeden Morgen zwischen 6 und 8 Uhr reinblasen, und die dann an 10 andere Server weiterverteilt werden.
Bei einem sehr großen deutschen Konzern lief eine Firebird/Delphi basierende Software mit nachmittags durchschnittlich
1500 parallelen Usern. Wenn das mit dataset/datasource/lookup gemacht wäre, hätten schon 150 Leute damit nicht
mehr arbeiten können.

Der Rückschluss, den ich dir zugestehe, ist der, das Firebird mit datasource/dataset/lookup sicherlich nicht das Non
Plus Ultra ist, aber da sollte man Ursache und Wirkung nicht verwechseln.