Fragen bezüglich Performance von Firebird in einer Anwendung

[Codehunter]

Ich habe jetzt erst brandaktuell wieder so einen Fall gehabt (FIBplus-spezifisch): Funktion A arbeitet eine Schleife ab. Je Schleifendurchlauf wird ein if Dataset.RecordCountFromSrv > 0 then ... gemacht. Das Problem dabei: RecordCountFromSrv setzt intern ein "SELECT COUNT(*) FROM x" ab. Im Delphi-Quelltext kaum zu sehen, der Performance-Flaschenhals. Ich habe einfach vor der Schleife 1x das RecordCountFromSrv in eine lokale Integer-Variable zwischengeparkt. Schwuppdiwupp 10 Sekunden pro 500 Datensätze gespart.

[kretabiker]

Kannst du nicht eine der SQL-Abfragen mal rausziehen und in einem DB-Tool für Firebird ausführen? Mit Ausführungsplan, um zu sehen, wie FB die Query umsetzt. Da fummeln dann auch keine Client-Apps mit seltsame Dingen zwischen (wie vergessene BeginUpdate/EndUpdate).

Allein anhand der TCP-Pakete zwischen Client und Server würde ich nicht gehen, zumindest früher war da FB-Protokoll recht geschwätzig und hat ne Menge ChitChat auf dem Kabel erzeugt.

Du schreibst außerdem, dass die App früher BDE-basiert war. Ihr arbeitet aber schon mit optimierten SQL-Statetments und nicht mit TTable-Abkömmlingen?

[jobo]

Zitat von kretabiker:

Kannst du nicht eine der SQL-Abfragen mal rausziehen und in einem DB-Tool für Firebird ausführen? ..

Du schreibst außerdem, dass die App früher BDE-basiert war. Ihr arbeitet aber schon mit optimierten SQL-Statetments und nicht mit TTable-Abkömmlingen?

Der Server ist nicht ausgelastet, keine der Bestandteile, schreibt der TE, also das wird nicht viel bringen.

Da es sich scheinbar um irgendeine offizielle Kaufsoftware handelt, wird die Information über TTable Nutzung wohl kaum zu bekommen sein.
Auch wenn es vom Verhalten her passen könnte. Aber eigentlich wäre auch hier fraglich, warum der Client Wartezeiten hat (langsam ist) und der Server sich langweilt.

[jobo]

Zitat von Codehunter:

RecordCountFromSrv setzt intern ein "SELECT COUNT(*) FROM x" ab. Im Delphi-Quelltext kaum zu sehen, ..

Ja, sowas meinte ich mit unbekannten Komponenten. Dieses Phänomen kenne ich auch aus Dot Net. Eine coole Komponente aus dem Regal genommen und im Livebetrieb geht nichs mehr. Eigentlich ging es um DB Server Tuning, aber das bringt wenig, wenn die Anwendung versucht, zum Start die ganze DB zu laden.

[IBExpert]

Wenn du Lust hast, dann sende mir doch mal hier oder per email an [e-mail] eine genauere Beschreibung, welche Software das ist.

Wir kennen da einige, bei denen man an einigen Schräubchen drehen kann, aber so manch eine Software ist aufgrund der Architektur nicht wirklich
für größere Benutzerzahlen geeignet. Und das hat meistens als Grund die Unwissenheit der Programmierer, manchmal aber auch nur bescheuert formulierte
SQLs, und gerade diejenigen Firmen, die die Firebird Features wenig nutzen, sind da oft sehr ignorant gegen externes Consulting. Das eine Verabeitung
in einer SP gegenüber der externen Delphi basierende Verwurstung 10-50 mal schneller sein kann, wird mangels Basiswissen oder
aufgrund von sinnlosen Programmierrichtlinien gerne ignoriert, so lange bis dann irgendwann eine Auswertung nicht mehr über Nacht fertig wird.

IBExpert hat ziemlich viele Funktionen für das Monitoring und Tracen von Anwendungen, und extra Tools können dann auch auf tcp/ip ebene
weiterhelfen, um zu verstehen was da los ist.

Wenn deine Server CPU sich aber langweilt, dann liegt das meistens daran, das der auf den Datenträger wartet. Und das kommt bei vielen
nvme ssds aufgrund des gruselig schlechten nvme Treibers von Microsoft, viele SSD Hardwarehersteller bieten aber gar keine treiber für die Windows
Server versionen, warum auch immer (mal abgesehen davon, das man dafür nur die nahezu baugleichen teuren Servervarianten der SSDs
verkaufen will, die aber außer anderer Firmwarenamen und einem anderen Aufkleber meistens nicht besser sind).

Bei größeren Firmen rechnet es sich auch schnell, mal bei uns einen Consulting Tag vor Ort zu buchen, damit alle Mitarbeiter nicht endlos genervt sind
vom teuren neuen lahmen server. Anfrage dazu auch gerne per email.

Wenn der Softwarehersteller da wirklich Interesse dran hat, dann sollte man den gleich mit ins Boot nehmen, wenn man feststellt, das es in der
Software auch viel Optimierung machbar ist. Leider ist die Realität aber so, das Softwarehersteller manchmal ziemlich beratungsresistent
sind und viel zu geizig, um das eigene Personal mal mit den erforderlichen Werkzeugen das erforderliche Know How zu vermitteln, das man braucht,
um keine berechtigterweise meckernde Kunden dauernd am Telefon vertrösten zu müssen und anzulügen, das die Performanceprobleme immer nur bei dem
auftreten, der gerade anruft.

Wie sagt Thorsten Sträter immer noch so schön in seinem Liveprogramm: Wenn man nicht schwimmen kann, liegt es an der Badehose.

Und das ewige "andere Datenbanken können alles viel besser" in einigen Posts bringt auch niemanden weiter. Man kann mit jeder Datenbank und mit jeder
Programmierumgebung komplette Scheisse zusammenbauen oder seine Werkzeuge so beherrschen, das die Software auch größere Datenmengen in sinnvoller
Geschwindigkeit verarbeiten kann.

Wir haben in Projekten mit Firebird mit Datenmengen zu tun, bei denen die meisten Lösungen dicke Backen machen und so wie wir Firebird einsetzen,
machen auch Millionen neuer Datensätzen jeden Tag über mehrere Jahre repliziert auf 180 Server verteilt in ganz Deutschland kein Problem. Wer aber
mit seiner Software vor 20 Jahren als kleine Handwerkerlösung mit 2 Kunden und 3 Arbeitsplätzen angefangen hat und sich heute noch damit rumärgert,
wie er das damals verbockt hat, der muss nicht alles gleich wegschmeissen, wenn auf ein mal hunderte Kunden mit je bis zu 100 Anwendern mit der
gleichen Software arbeiten sollen, sollte aber dringend mal in eine Evolution investieren.

Schaut euch eure Delphi Projekte einfach mal an, dutzende Datasets in jedem der dutzenden Formulare verteilt mit endlos SQLs oder Tables und TFieds
in den dfm dateien war schon vor 20 Jahren ein Scheiss Design, wenn man die Software dynamisch im Team weiterentwickeln möchte.

So ein Design sorgt auch regelmäßig dafür, das Datenbanklimits wie langlaufende Transaktionen nicht mehr so einfach in den Griff zu bekommen sind,
schon gar nicht wenn man gar nicht weiß, warum das bei Firebird ein Problem sein kann und das das Problem dabei nicht Firebird ist, sondern der
Programmierer, der seit Handwerkszeug nicht beherrscht.

So, genug gemeckert, wie schon gesagt, meld dich einfach (oder auch andere, die unsere Hilfe brauchen), den Benchmark machen wir nach Termineabsprache
auch gerne kostenlos per Fernwartung (dauert ca. 10-20 minuten, wenn euer Server nicht kompletter Schrott ist) dann habt ihr einfach mal einen
Vergleichswert, was eure Serverinstallation an Firebird Speed so kann.

Single Threded insert/update/delete scripte bringen da nur sehr wenig Erkenntisse, das was unser Benchmark da macht ist schon aufwändiger
und multithreaded.

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