Fragen bezüglich Performance von Firebird in einer Anwendung

[p80286]

Du hast ja sooo recht.

Gruß
K-H

[IBExpert]

Zitat von p80286:

Du hast ja sooo recht.

Gruß
K-H

Danke, daher hier gleich noch ein paar mehr Gedanken dazu:

Es ist oft die übliche Situation, auf die ich treffe: Motivierte neue Mitarbeiter mit gehobenen Kenntnissen scheitern am "Chefdesigner" (der oft auch Chef ist), der argumentiert, das das schon immer so gemacht wurde und da es ja funktioniert und die Software verkauft wird, auch nicht so schlecht sein kann.

Das die Branchenlösung meistens nur mangels alternativer Lösungen für die gleiche Branche eher auf Basis von Erpressung vom Kunden weiter benutzt wird, weil die nix anderes finden, wird dabei gerne von der Unternehmensleitung ignoriert, es sei den ein Wettbewerber kommt da auf einmal in die Quere und bietet auch nur ähnlich gute Branchen-Prozessqualität, aber mit wesentlich besser und schnellerer Bedienung der Software.

Dann wird man auf einmal hektisch und wirft alles über den Haufen, am besten noch Delphi ganz wegschmissen, Visual Studio .NET oder Java ist ja viel besser und es gibt ohne Ende verfügbare fähige Mitarbeiter, die das mal eben auf der Neuen Plattform zusammenbauen (was schon mal Bullshit ist, Verfügbarkeit von fähigen Programmierern ist im deutschsprachigen Raum eine Sozial- und Geldfrage. Wer in dieser Branche aktuell keinen Job hat, will entweder nicht wirklich einen Job, weil er nicht von seinem Heimatort weg will, übertriebene Vorstellungen von seinem Wert hat oder einfach nicht auf dem Level ist, auf dem er sich selber gerne sieht).

Techniken wie Entity Framework usw. liefern ja in der Präsentation für die Entscheidungsträger schnelle Prototypen, so das das alles ganz toll aussieht.

Der typische Delphi Programmierer im Team, der nun eigentlich nur noch den Quellcode am Leben halten soll, bis das neue Produkt dann von den Klugschnackern in spätestens 2 Jahren fertig ist, stellt sich eben auf Dienst nach Vorschrift mit anschließender Kündigung ein und wartet halt ab was da kommt, sucht aber evtl schon mal, ob nicht auch andere Mütter schöne Töchter haben, spricht neuer Arbeitgeber ist auf einmal gar nicht mehr so unwahrscheinlich wie vorher.

2-3 Jahre später ist der neue Kram immer noch Prototyp und unbenutzbar, der Delphi Programmierer hat mit wesentlich kleinerem Team trotzdem 2-3 Jahre lang das Produkt verbessert und die Klugschnacker mit der neuen Plattform überbieten sich dabei, neue Ausreden zu finden, warum man noch nicht so weit ist wie man dachte. Irgendwann merkt dann auch der blödeste, das da was schief läuft ...

Wenn der Neueinsteiger aber schon vorher versucht, seine Aufgaben mit optimaler Performance umzusetzen und diese Kenntnisse in der gesamten Produktentwicklung zu etablieren, das Stammpersonal dabei aber meistens ja schon mit kleinen Detailtechniken überfordert und oft aufgrund des Alters >=50 ziemlich ignorant ist, die eigenen Kenntnisse in Frage zu stellen oder auch nur zu kapieren, was physikalisch abläuft, dann leidet nicht nur das eigene Selbstbewusstsein für den Neueinsteiger, sondern auch die generelle Motivation.

Und selbst eigentlich banale und auch mit Grundschul-Physikkenntnissen nachvollziehbare Vorgänge werden ignoriert.

Dazu ein Beispiel aus der Delphi/Firebird Welt:

Wenn du einen execute block mit einem tcpip paket und 200 inserts darin vom client zum server sendest und der mit seinem cpu/ssd speed das dann abarbeiten kann, dann geht das kaum schneller.

Wenn aber der ignorante Kollege, der zwar mal vor 20 Jahren gelesen hat, das parametrisierte Queries besser sind, bei prepare und transaktionen aber nicht mehr aufgepasst hat, Wert darauf legt, das es immer so gemacht wird wie er das will, der sollte dann folgendes wissen: Pro parambyname werden mehrere tcpip packages hin und her jagt. Wenn er aber gar nicht hinterfragt, warum das 50 mal länger dauert wie die schnelle execute block Version, dann ist es schwierig, den zu überzeugen, wenn die Hierarchien es nicht hergeben.

Auf seinem lokalen Entwicklungsrechner mit kleiner Test-DB und schneller SSD merkt er auch kaum einen Unterschied, also behauptet er einfach, das der Kram mit execute block quatsch ist.

Das sind nämlich bei zB 200 inserts mit je 50 Spalten dann eben mal ca. 50000 tcpip pakete. Diese dann multipliziert mit der Ping zeit (auch im Ms bereich) und 100 andere Clients, die den gleichen Müll programmiert haben, erstickt jedes Netzwerk ...

Bei genauer Analyse kommt zuerst fast immer eine Ausrede nach der anderen warum das so ist wie es ist, dann die Erkenntnis, das man was machen kann und muss. Die Dataset-Datasource Architektur ja ganz lustig ist für Mini Anwendungen, im Enterpriseumfeld hat die aber nix zu suchen und selbst bei kleineren Installationen ist die oft schon Unsinn, weil keiner eine klare und vollständige Aussage machen kann, was passiert, wenn man zB. auch nur eine Rechnung abschließt, weil keiner einen Überblick hat über die wild verschachtelten Events, die dann auch noch selber in der Datenbank rumkaspern.

Spätestens der Blick dabei ins Netzwerkprotokoll macht auch dem Blindesten deutlich, das Daten nachgeladen werden, die aber auch gar nicht mit dem aktuellen Vorgang zu tun haben. Der ach so schlaue Supertarchitekt hinter dem Quellcode sucht dann seine Ausreden zusammen, und dann hör ich immer wieder, das die Komponenten schuld sind, usw.. Erst später merkt er, das die Komponenten nur das machen, wofür er die einsetzt. Wenn du dir mit dem Hammer dauend auf den Finger haust, ist es ein Fehler, dafür den Hammer verantwortlich zu machen ...

Das Problem ist ja oft das der Prophet im eigenen Lande nichts wert ist, daher ist es insbesondere für einen Neueinsteiger im Unternehmen immer schwierig, den alteingesessenen Platzhirschen mal die Meinung zu geigen.

Wenn die Unternehmensleitung aber ein echtes Interesse aber eine Verbesserung hat, dann stehe ich für so was gerne bereit, weil ich nach meinem Auftrag wieder nach Hause fahren kann. Jedes Pseudo-Argument für beschissene Programmierung wird von mir auch als solches aufgezeigt, aber eben direkt mit Hinweise wie es besser geht und wie man es auch besser macht.

Die meisten Kunden, die mich für solche Aufträge gebucht haben, sind übrigens Wiederholungstäter und ein paar Wochen nach der erfolgreichen Umsetzung der ersten Optimierungen durch das eigene Team laden die mich dann wieder ein, um die neuen Kenntnisse auszubauen und neu aufgetretene Fragen entweder im extra Workshop zu klären oder per Hotline und Remote-Session zu diskutieren. Nicht selten kommt es dabei vor, das Mitarbeiter "der alten Garde" dabei dann schon gar nicht mehr dabei sind ...

Im Rahmen unserer Hotline Pakete machen wir übrigens auch einfach schon mal Remote Sessions, um das Netzwerkprotokoll bei Funktionen zu untersuchen, die unerklärlich langsam sind, das geht auch mit geringerem Budget ...

[jobo]

Zitat von IBExpert:

Zitat von p80286:

Du hast ja sooo recht.

Gruß
K-H

Danke, daher hier gleich noch ein paar mehr Gedanken dazu:
...

Das klingt schon etwas differenzierter als der vorige Beitrag von Dir.
Am Ende sind es nicht einfach nur die Entwickler, sondern durchaus komplexe Sachverhalte, die dann zu Deinen Erfahrungen führen.

Denn mal ehrlich, solange alles einigermaßen gut läuft, meldet sich niemand freiwillig, um teure Datenbankspezialisten nach Verbesserungen zu fragen. Jedenfalls nicht, solange Verträge und Beziehungen zu Softwareentwicklern oder Lieferanten bestehen, die man nutzen kann. Deine Perspektive ist also nicht falsch, aber eben auch nur eine Perspektive auf eine Gesamtsituation, die m.E. nicht so schlecht ist, wie Du sie darstellst.

[IBExpert]

Zitat von jobo:

Denn mal ehrlich, solange alles einigermaßen gut läuft, meldet sich niemand freiwillig, um teure Datenbankspezialisten nach Verbesserungen zu fragen. Jedenfalls nicht, solange Verträge und Beziehungen zu Softwareentwicklern oder Lieferanten bestehen, die man nutzen kann. Deine Perspektive ist also nicht falsch, aber eben auch nur eine Perspektive auf eine Gesamtsituation, die m.E. nicht so schlecht ist, wie Du sie darstellst.

Das stimmt, die Vorwürfe, die ich da mache, betrifft keineswegs jedes Softwarehaus oder Entwicklungsabteilung in größeren Unternehmen, aber leider viel mehr als man denkt.

Ich kann aus meiner Erfahrung sagen, das es auch viele Kunden gibt, die sehr wohl gerne neue Techniken und Architekturen kennen lernen und umsetzen, weil das in Ihren Produkten schnell umgesetzt werden kann. Die sind halt dann aufgrund entsprechender Vorkenntnisse meistens auch in der Lage, das eigene Framework schnell an neue Gegebenheiten anzupassen.

Wir hatten vor einigen Monaten mal für einen Kunden den Auftrag, seine Firebird DB Struktur Multimaster-Replikationsfähig zu machen. Nach einem Workshop und Sichtung seiner Datenbank war mir relativ schnell klar, welcher Aufwand das wird und was der Kunde an seinem Datenmodell anpassen oder ändern sollte. Üblicherweise sorgen wir dafür, aber dieser Kunde hat von uns im Rahmen des Workshops genaue Vorgaben bekommen, was wir machen würden und das hat er dann innerhalb weniger Wochen in sein Projekt bereits integriert, weil er wie er sagte da eh noch ein paar Baustellen hat und das dann gleich mit erledigen kann.

Als er dann damit fertig war, haben wir unser Angebot zur Integration der Replikation noch mal auf Basis der nun wesentlich besser zu benutzenden Datenbankstrukturen überarbeitet und sind dann vom ursprünglichen Angebot 9000€ runter auf 6000€ gegangen und haben das gesamte Projekt dann beauftragt bekommen und komplett im vereinbarten Zeitplan umgesetzt, inkl. diverser gemeinsamer Sessions, bei denen der Kunde dann auch komplett verstanden hat, wie das ganze umgesetzt wird und funktioniert.

Er hatte seine Softwarearchitektur so gut im Griff, das er auch ziemlich heftige Änderungen am Datenmodell schnell im Front End umsetzen konnte und hat nun ein weiteres Feature in seiner Software, die für seine Kunden extrem wichtig ist.

[p80286]

Zitat von jobo:

Jedenfalls nicht, solange Verträge und Beziehungen zu Softwareentwicklern oder Lieferanten bestehen, die man nutzen kann. Deine Perspektive ist also nicht falsch, aber eben auch nur eine Perspektive auf eine Gesamtsituation, die m.E. nicht so schlecht ist, wie Du sie darstellst.

Für die Gesamtsituation magst Du recht haben, aber mir ist ein Fall untergekommen der knapp an Schlangenöl heran reichte, aber von einem zugegeben erstklassigen Verkäufer als das technisch absolute NonPlusUltra verkauft wurde. Und welcher Entscheider würde schon zugeben, daß man ihn über den Tisch gezogen hat.
(Statt eines Views eine sog. Mastertabelle die über den Client gepflegt wurde[spätestens nach einer Woche liefen die Inhalte auseinander]. Constraints und Trigger wurden nicht eingesetzt um eine möglichst hohe Flexibilität zu erreichen.)


Gruß
K-H

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