Fragen bezüglich Performance von Firebird in einer Anwendung

[jobo]

Natürlich kommt das vor und ich will ja sowas gar nicht ausschließen. Letztlich kennt es jeder auch aus dem privaten Bereich (ich bin z.B. gerade mit meinem Wagen bei diversen Werkstätten gewesen, da freut man sich dann tatsächlich schon darüber, wenn die einfach sagen, kenn ich nicht, mach ich nicht)
Aber es ist nicht die Regel und nur "die Entwickler" dafür zu schellten ist unfair, wie auch Dein Schlangenöl-Beispiel zeigt. Es sind immer einige Karten im Spiel, Verkäufer, Geschäftsführer, Budgetgrenzen, Termine ...
Und so gehören zu solchen "Deals" immer auch mindestens 2 Seiten. Ob es die Leistung ist (Schlangenöl) oder der (niedrige) Preis, im englischen sagt man frei übersetzt, "es gibt kein kostenloses Mittagessen"
Wenn man etwas für verdächtig wenig Geld bekommt oder die erbrachte Leistung gar nicht versteht, Mehraufwände hat, etc.. und trotzdem das Geschäft macht, bei wem liegt dann die Verantwortung?
Die Krönung ist natürlich eine nicht erkennbare Leistung für viel Geld, aber das ist ja nicht das Thema.

Geschäftsbeziehungen haben etwas mit Vertrauen zu tun, das müssen sich beide Seiten erarbeiten. Preisdrückerei auf der einen Seite und unsachgerechte Leistung auf der anderen Seite sind nicht Vertrauen fördernd, ebensowenig wie das berühmte Schwarze Peterspiel (in diesem Fall hier "die Entwickler sind schuld").

IBExpert hat ja in seinem letzten Beitrag die Vielschichtigkeit dieser Problematik ganz gut beschrieben und damit die erste Aussage relativiert.

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

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