Fragen bezüglich Performance von Firebird in einer Anwendung

**jobo**

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.