Fragen bezüglich Performance von Firebird in einer Anwendung

[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 von IBExpert:

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.

[jobo]

Also ich finde, man kann erstmal niemand vorwerfen, dass er das System nutzt (und dabei überfordert bzw. nicht optimal arbeitet).
Und diese Dataset Klamotten und die datensensitiven Komponenten sind ja immerhin ein Teil der Erfolgsgeschichte. Warum soll ich mit Delphi ein RAD Tool einsetzen, mit dem ich aber lieber nicht RAD Entwicklung mache, sondern die DB schone?

Es gibt eine Geschichte -ich weiß nicht, ob sie stimmt- von einem Deutschen LKW Hersteller in Indien, wo ständig die Wagen zusammengebrochen sind und die Kunden sich beschwert haben. Der Hersteller hat gesagt, Ihr habt den Wagen überladen, das ist gegen die Nutzungs- und Garantiebestimmungen. Und die Kunden haben gesagt: Ich habe den Wagen einfach nur voll geladen.
Da der Hersteller in diesem Markt Fuß fassen wollte, hat er begonnen, seine LKW stärker auszulegen.

Mir ist ehrlich gesagt nicht klar gewesen, dass es so drastische Unterschiede gibt zwischen den System. Zu Delphizeiten habe ich mit Oracle gearbeitet. Nun arbeite ich viel mit Postgres, das sich angeblich ähnlich (schlecht) schlägt, wie Firebird. Das Phänomen ist mir aber in Webprojekten mit Postgres noch nicht aufgefallen.

Die Frage wäre doch nun, wie man dieses Manko aus Datenbanksicht erklären und ausbessern kann, ohne dabei alles umzukrempeln (in den Client Programmen). Denn das ist ja in vielen Fällen clientseitig offenbar aussichtslos (Aufwand).

Und es sind ja auch schon gute Punkte genannt worden.

Wieso nimmt Firebird sich nicht den verfügbaren Hauptspeicher, so dreist wie es MSSQL macht?! Es gibt sicher nichts schnelleres, als alles was geht im Hauptspeicher zu puffern! Vielleicht weil FB auch eine süße, kleine embedded DB ist und das einfach in den Köpfen der Entwickler rumwabert? Welches Feature macht da den Unterschied?
Wieso macht es Postgres nicht? Die Systeme laufen standardmäßig auch auf Raspy & Co und das ist eine Hardwareausrüstung, die vor 20 Jahren noch Desktop/Server Niveau war, heute ein Witz für Server. Teuren Speicher nahm man sich nicht einfach so. Aber, Speicher ist nicht mehr teuer. Warum nicht mal die Schleusentore öffnen? Das großzügiger zu handhaben dürfte doch nicht so ein Riesenfeature sein.

Ganz klar, ich bin nicht dafür, stumpf seinen inperformanten Standard Code abzuliefern, im Gegenteil. An vielen Stellen muss man halt erstmal drauf kommen, wie es besser gehen könnte. Dabei helfen solche Threads ja vielleicht.
Aber ich sag auch:
Wenn man von Delphi Entwicklern fordert, dass sie endlich mal ihre Hausaufgaben machen, dann fordert man das doch am besten auch von den Programmieren der Datenbank oder?

[hoika]

Hallo,
also ich hatte ja schon geschrieben.

Wir benutzen nur FB.

Jede Query bei uns wird geprüft, ob sinnvolle Indices vorhanden sind usw..
Und das bei verschiedenen DB-Größen (Stichwort Selektivität),
Das erfordert einen großen Aufwand, der sich im Endeffekt aber rechnet.
Trotzdem fallen wir manchmal doch rein, wenn z.B. ein Index sogar bei einem Select bremst,
kann passieren, kommt aber selten vor.

Wir benutzen übrigens keine TDB-Komponenten (aka datensensitiv).
Alle Listenanzeigen kommen in <TList>'s und werden über entsprechende Grid-Renderer "bearbeitet".

Viele Queries sind es nicht, die pro Arbeitsschritt (=Workflow) gestartet werden,
vielleicht mal 20/30, aber das sind dann schon viele.

Deshalb komme ich nicht in das Problem "FB viele Queries -> doof".

[IBExpert]

Zitat von jobo:

Wieso nimmt Firebird sich nicht den verfügbaren Hauptspeicher, so dreist wie es MSSQL macht?! Es gibt sicher nichts schnelleres, als alles was geht im Hauptspeicher zu puffern! Vielleicht weil FB auch eine süße, kleine embedded DB ist und das einfach in den Köpfen der Entwickler rumwabert? Welches Feature macht da den Unterschied?

Gerne ein wenig Erklärung dazu: stell dir mal vor du hast eine 100GB DB mit 100 tabellen die jeweils 1GB belegen, deine Abfrage beziehen sich aber ausschliesslich auf Daten einer Tabelle, deren Rohdaten 1GB belegen (nennt man bei firebird datenpages, indexpages, und noch ein wenig krams aus kleineren Systemtabellen und transaktionsdaten).

Ein ganz banaler select count() auf dieser Tabelle kann von Firebird nur dann beantwortet werden, wenn jede Recordversion auf sichtbarkeit/gelöscht geprüft wurde für den Transaktionskontext, aus dem das aufgerufen wurde. Repeatableread connections können zB andere Anzahlen sehen als Readcommitted usw.

Wie behandelt firebird nun deine Abfrage:

Es lädt sich alle erforderlich Pages von der Platte in den RAM und im RAM wird das dann auseinandergefrickelt.

Nehmen wir an, deine DB benutzt den Superserver 2x oder 30, bei dem es einen gemeinsamen Cache für alle gibt. In Tools wie IBExpert siehst du dann das zB der Wert Reads beim ersten Zugriff ziemlich hoch ist, reads sind die pages, die von platte in den RAM geladen wurden. Gehen wir mal davon aus das du 16k Pagegröße beim Anlegen der DB benutzt hast und als cache buffers 100000 eingestellt hast. Damit weiss firebird, es kann bis zu 1,6 GB RAM fest benutzen. Deine komplette Tabelle belegt aber gerade mal 1GB, also ca 65000 pages. In den Reads wirst du sehen, das zu deinem SQL 65000 pages in reads stehen und die wurden auch im Speicher in etwa nun physikalisch belegt +x für das was der prozess eh braucht.

Warum aber Firebird irgendwas in den RAM packen sollte was keiner wissen will, erschliesst sich mir nicht.

Nun kommt der zweite Client und will auch noch mal einen Count wissen. Was passiert? Firebird nimmt das SQL entgegen,analysiert dazu wie schon beim ersten Mal die erforderlichen Pages und merkt beim Superserver, huch, die sind ja schon im Speicher, also brauch nix nachgeladen werden, sondern es kann gleich im RAM losgehen. In den Reads liest du nun übrigens auch 0 , d.h. alles was gebraucht wird, war schon im ram.

Solange nicht alle zugewiesenen CachePages belegt sind und für andere Pages weiterer RAM gebraucht wird, wird firebird superserver die daten auch nicht mehr aus dem ram rausschmeissen, es sei denn, die letzte Connection meldet sich dann auch noch ab und es ist kein Client mehr verbunden. Sobald jemand dann neu kommt geht das wieder von vorne los, wenn man das vermeiden möchte lässt man immer einen client aktiv.

Es ergibt aber immer noch keinen sinn, die nächten 100GB RAM mit Tabellen vollzumüllen, die keiner braucht. Schon gar nicht auf einer Maschine, die eben nicht 1GB RAM frei hat (Bedenke, es gab bis vor einigen Jahren und auch heute noch 32bit Versionen von Datenbanksystemen, die bei 2GB dicke backen machen. Firebird kann auch als 32bit Version im Gegensatz zum Beispiel zu MS Access mdb auch eine 10TB Datenbankdatei öffnen und sauber verwalten, aber prozesstechnisch gehen da nicht mehr als 2GB RAM in der 32 Bit Welt).

Und spätestens bei der 2TB Datenbank könnte es eng werden mit alles im RAM.

Sicherlich erfordern komplexe Abfrage mit group by etc einiges mehr an RAM, Global Temp Tables arbeiten komplett im RAM oder Recordversionen, Tempspace ist zunächst ram, wenn aber mehr gebraucht wird, ausgelagert, aber das ist alles konfigurierbar, wen man es braucht und der RAM da ist. Firebird läuft aber auch heute noch auf minimal Hardware mit vollem Funktionsumfang und insbesondere mit Betriebssystemen wie Linux ist das sehr gut skalierbar. Und die Standard Konfiguration ist nicht so schlecht, mit falschen Parametern kann man auch viel falsch machen.

Zu viel RAM muss übrigens kein Vorteil sein, weil dann ggf zu ändernde Pages wesentlich länger im RAM bleiben und erst mit dem Commit auf den Datenträger geschrieben werden (das aber eben mit forced writes in einer extrem robusten reihenfolge, die bei windows ohne forced writes verändert wird und ein servercrash ohne forced writes auf windows gerne mal in einer kaputten datenbank enden kann. Unter linux kann ich das auf filesystemeben vermeiden und deutlich besser optimieren, als das was windows in ntfs das selber macht. Bei Dialogsoftware kommt dann unglücklicherweise beim speichern eine Wartezeit zustande, die der Anwender merkt, aber bei kleinerem Cache wären die Pages ggf zum Teil schon vorher wieder auf dem Datenträger.

Microsoft SQL Server ist von Microsoft und hat halt unter Windows die Angewohnheit zu sagen, der Rechner gehört mir und nur wenn was übrig bleibt, kann das jemand anders haben.
Welche Tricks da laufen weiß ich nicht, aber ein von mir mal auf Linux gemachter tpc Benchmark mit Firebird30 und MSSQL auf Linux brachte eine überraschend ähnliche Leistung, bei der Firebird aber sogar noch besser war, der erreichte tpc Wert für den MSSQL Server auf dieser Maschine (Kosten ca 4000€) aber laut Vergleichstabelle dieses tpc benchmarks in Bereichen lag, die ansonsten kein aktueller Windows mssql server unter 40000 US$ gebracht hat.

Leider hab ich das nicht gut dokumentiert und müsste das ggf ncoh mal zusammensuchen, aber wer weiß, wenn ich zeit hab mach ich das noch mal.

Wie schon geschildert, MSSQL mag scheinbar mit dataset/datasource/lookup/master-detail Delphi Applikationen wie besser klarkommen, es ist aber für optimierte Anwendung nicht annähernd 4-10 mal schneller.

btw: RAM und x4 m.2 SSDs sind vom Speed her nicht mehr so unterschiedlich, Ram ist bei größeren Blöcken oft gerade mal doppelt so schnell, wenn überhaupt. Mach einfach mal benchmarktests auf ssd und auf Ramdisk, das ist je nach Aufgabenstellung meiste nähere aneinander als man erwarten würde.

[Codehunter]

Also wenn man die Changelogs zu FB 4.0 liest merkt man schon, dass die Entwickler eine Flaschenhälse im Netzwerkinterface von FB angegangen sind. Speziell bei vielen kleinen Anfragen trennt FB sehr früh die TCP-Verbindung, sodass die neu ausgehandelt werden muss. Insofern würde ich sagen, schaukeln sich hier die Eigenarten von FB und Delphi gegenseitig zu einem Problem hoch.

Aus den o.g. Gründen bewirken Einstellungen am DB-Cache auch verhältnismäßig wenig. Und umso stärker wirkt sich das Problem aus, je mehr Clients am Server hängen und je schlechter das Netzwerk konstruiert ist (z.B. billige Switches mit minimalem ARP-Cache, Mesh-WLAN etc.).

In der Konsequenz müssen Delphientwickler die FB nutzen, einen erhöhten Aufwand betreiben, performante Clients zu schreiben. Damit wird der Gedanke, der hinter RAD mal stand, ad absurdum geführt. Die Tatsache, dass es Spezialisten (neudeutsch "Berater") braucht, die Delphientwickler coachen, bestätigt das ja ein Stück weit. Klar kann man mit FB performante Anwendungen schreiben. Kann man wohl mit jedem aktuellen, auf heutige Multicore-CPUs optimierten DBMS.

Die entscheidende Frage ist: Mit welchem DBMS kann man mit Delphi am schnellsten das RAD-Konzept umsetzen? Intuitiv so, wie es mal von Borland gedacht war. Die Antwort möge jeder sich selbst geben...

[Schokohase]

Dieses RAD ist ja ganz nett für ein Prototyping, "schnell mal was darstellen" oder wirklich einfache Projekte.

Aber sobald das Projekt anfängt ernsthafter zu werden und eine gewisse Komplexität erreicht, dann sollte man sich von RAD verabschieden und die Anwendung in Schichten aufbauen.

Bei RAD bekommt man keinen (unabhängig) testbaren Code (Unit-Tests) und das sollte ab einer bestimmten Komplexität ein NO-GO sein.