|
Datenbank: FIREBIRD • Version: 2.5 & 3.0 • Zugriff über: FIREDAC
Fragen bezüglich Performance von Firebird in einer Anwendung
Guten Tag,
ich bin neu hier im Forum und möchte zunächst mal alle Experten hier begrüßen. Ich habe nun aktuell bereits eine Frage, die mich seit einiger Zeit beschäftigt. Wir nutzen intern eine Businesssoftware (ERP) die im Hintergrund eine Firebird 2.5 bzw. Firebird 3.0 Datenbank verwendet. Da wir die Performance der Anwendung verbessern wollten, haben wir den bestehenden Server auf dem die Firebird Datenbank bisher lief aktualisiert. Der alte Server hatte folgende Hardware: Intel XEON E5-2630 v4 2.10 GHz 64 GB RAM HP SSD Drive für die Datenbank mit folgenden Werten: RANDOM READS : 64000 IOPS RANDOM WRITES : 26000 IOPS SEQUENTIAL READS : 535 MBPS SEQUENTIAL WRITES : 380 MBPS Gigabit Netzwerkkarte Um mehr Performance zu erhalten haben wir den Server ersetzt und anstelle einer normalen SSD die Datenbank auf eine NVMe Festplatte gelegt. Der neue Server hat folgende Daten: Intel XEON Silver 4215 2.5GHz 32 GB RAM (hier wurde weniger verwendet, da der RAM sowieso nie voll belegt war) Intel DC P4510 NVMe Drive mit folgenden Werten: Sequenzielle Lesezugriffe (bis zu) 3200 MB/s Sequenzielle Schreibzugriffe (bis zu) 2000 MB/s Zufällige Lesezugriffe (Bereich: 100 %) 637000 IOPS Zufällige Schreibzugriffe (Bereich: 100 %) 81500 IOPS Gigabit Netzwerkkarte Beide Server sind am selben Netzwerkswitch angeschlossen und nicht virtualisiert. Nachdem die Datenbank umgezogen war, habe ich entsprechende Performancetests ausgeführt. Wenn ich z.B. den Test von IB-AID  https://ib-aid.com/en/simple-insert-upd ... -firebird/ ausführe, dann ist mein neuer Server auch deutlich schneller als der alte.Leider, und das ist das Problem, merken wir das in der Anwendung nicht. Diese ist, wenn überhaupt, nur minimal schneller. Ich vermute ja dass es an der Anwendung liegt. Daher habe ich parallel zur Arbeit in der Anwendung mal einen Test mit procmon durchgeführt und die Log-Datei von procmon überprüft. Es ist auffällig dass sehr viele TCP-Requests bei Aufruf von DAtensätzen in der Anwendung stattfinden. Ist das für Anwendungen, die Firebird als Datenbank verwenden normal oder liegt dies in der Art und Weise der Programmierung? Da innerhalb der Datenbank relativ wenig mit StoredProcedures, Triggern etc. gearbeitet wird und die SQLs rein aus der Anwendung heraus passieren, stellt sich mir in der IT die Frage ob ich durch bessere Hardware überhaupt noch Geschwindigkeitsverbesserungen in der Anwendung erreichen kann. Hat hier jemand Erfahrung oder ähnliches schon erlebt? Vielen Dank. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Hallo,
Zitat:
Hier kann nur der Entwickler des Programmes eine Antwort geben. Es gab mal bei HK Software einen DB-Monitor, wo man die einzelnen SQL-Befehle protokollieren konnte, ohne das es die eigentliche Anwendung mitbekommt ... Ich finde den Monitor aber nicht mehr (habe den damals sogar selber gekauft). Firebird ist eine sehr performante Datenbank, die aber durch "etwas unglückliche" Programmierung auch ausgebremst werden kann. Da halte ich mich aber raus. "Programmierer-Ehre" ;) . Man könnte am DB-Cache etwas drehen. Firebird benutzt pro DB standardmäßig relativ wenig Cache. https://firebirdsql.org/manual/gfix-buffers.htmlZitat:
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Da passt
das hier ganz gut ins Bild. Firebird ist in puncto SQL doch recht beschränkt. Wenn Entwickler Erfahrung in Mysql oder Oracle haben, müssen sie gewaltig umdenken, sonst endet es genau bei den von dir beschriebenen Problemen. Für gute Performance muss man bei FB etwas tun, was eigentlich immer gelehrt wird nicht zu tun: Möglichst große Abfragen machen, lokal vorhalten und dort durchsuchen. Nur wird genau das bei Updates kontakariert, weil FB kein Multi-Row-Insert/Update beherrscht und man sich solcher Krücken wie Execute Blocks bedienen muss. Von FB 2.5 auf 3.0 wurde es etwas besser, nur nützt einem das nix wenn die Anwendung für 2.5 entwickelt wurde und die Abfragen entsprechend aufgebaut sind. Dann läuft FB3 sozusagen im Kompatibilitätsmodus und die Performance ist praktisch identisch.Mit anderen Worten: Die investition in einen Ferrari als Ersatz für den Mercedes SLK war vergeblich, weil die Straße eine Schlaglochpiste ist. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Ich würde das etwas differenzieren.
Hardware Einfache Rechenbeispiele: Wenn ich eine quad core CPU gegen eine octa core austausche, wie viel schneller wird dann mein Programm (unter Idealbedingungen)? Doppelt so schnell. Umgerechnet auf Wartezeiten: Aus 10 Sekunden Warten, werden 5 Sekunden. Das kann man für alle Hardwarebestandteile durchexerzieren. Die Rechnung ist immer die gleiche. Software Algorithmen können gut oder schlecht, passend oder unpassend sein. Das gilt für SQL, für Floating Point Arithmetik aber auch für Units und Komponenten (in Delphi). Optimierungen sind hier oft viel weitreichender möglich und bringen Faktoren, die Du mit (bezahlbarer) Hardware nicht ohne weiteres erreichen kannst. Also ja, man muss sich die Anwendung anschauen. Auch wenn Du es nicht beschrieben hast, Du wirst wissen, wo der Schuh drückt. Eine generelle Sache oder bestimmte "unangenehme" Ecken der Anwendung... Bei einer Client Server Anwendung spielen natürlich auch Netztopologie und Auslastung, -Konfiguration eine Rolle. Ich hatte noch nie den Bedarf eine Delphianwendung an den Paketscanner zu hängen, aber ja, sie arbeitet (im Datenbankverkehr) vollkommen anders als eine Webanwendung. Es wird viel hin und her geschickt. "Früher" war die Herausforderung, eine Anwendung notfalls über ISDN laufen zu lassen. Klingt vielleicht bescheuert, aber es geht und in solche Richtungen muss man immer denken, wenn man evtl. unbekannte/fremde Komponenten einsetzt oder ein koplexes Datenmodell anlegt bzw. abfragt. Was auf dem Entwicklerrechner geht, ist in der "Wildbahn", also z.B. Firmennetz mit 100en Clients und "Konkurrenzprogrammen" dann halt doch was anderes. Anwendung Oft sind es einfach noch relikte aus BDE Zeiten. Da wurden Tabellen einfach geöffnet. Geht anfangs immer prima, wenn sie so gut wie leer sind. Aber das bleibt ja im Normalfall nicht so. Auch wenn sich nur ein paar Tausend Datensätze ansammeln, das kann man hochrechnen mit der Anzahl der Clients. Jedes Schließen/Öffnen zieht dann eben immer wieder ein paar Tausend Datensätze. Auch wenn man einen SQL Server einsetzt, bedeutet das nicht, dass SQL als Abfragesprache zweckmäßig und Ressourcen schonend eingesetzt wird. P.S.: Datenbank Es ist sicher hilfreich, die aktuellste Version einzusetzen (Stichwort Sprachfeatures). Um die dann zu nutzen, muss man natürlich trotzdem an die Anwendung ran. Außerdem ist es so, dass natürlich der Hauptspeicher als Buffer eingesetzt werden sollte, soweit wie möglich (wenn nicht ständig nur Updates gefahren werden und nie ein Stein auf dem anderen bleibt) Bei heutigen RAM Ausstattungen ist die DB ja manchmal kleiner als der Hauptspeicher. Hat man in der Konstellation Performance Probleme, würd ich eher auf Netzauslastung bzw. unnötige (unnötig große,~undifferenzierte) Datenabfrage tippen. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Ich sage ja auch nicht, dass FB per se langsam ist. Nur braucht es spezielle Erfahrungen, die Möglichkeiten, auch im Zusammenspiel mit Delphi, richtig zu nutzen. Kommt man als Entwickler von anderen relationalen DBMS, dann kann man sich schnell verrennen. Ich sprech da aus Erfahrung ;-)
Der Hinweis vom Erstpost mit den vielen Verbindungen deutet auf ein spezifisches Designproblem bei der Clientanwendung hin. Dass es nur wenige Storedprocs gibt, bestätigt die These ein Stück weit. Insofern müsste der Anwender eher die Clients aufrüsten als die Server. Hier würde mir mein Bauchgefühl eher zu hochtaktenden 2-Kernern raten als zu Multicores. Schließlich sind (ältere) Delphi-Anwendungen in aller Regel immer noch Singlethread-Programme. Auch die Netzwerkstrecke müsste man sich anschauen. Switch ist nicht gleich Switch, es gibt große Unterschiede bei deren Performance. Aber bei aller Müh werden sich die so erzielbaren Verbesserungen in Grenzen halten. Ohne Optimierung der Anwendung würde ich sagen: Wirtschaftliche Sackgasse. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
Vielleicht mal so rum: Ich kann auch MSSQL oder Oracle DB ungünstig einsetzen. Und noch ein Nachtrag: Datenbank Tuning durch einen Fachmann kann in der Situation schon hilfreich sein. Es kommt halt drauf an. Wenn die Anwendung immer recht große Joins macht oder große Sorts, deren Volumen blöder Weise immer über der definierten Speichergrenze für JOIN oder SORT liegt, dann geschieht das immer auf Platte statt dass der Server "Kopfrechnen" (so nenne ich das immer) machen kann. Es werden also buchstäblich die (Zwischen-)Ergebnisdatensätze auf der Platte nebeneinander gelegt und sortiert.. Sollte bei einer Highend SSD auch kein Problem sein, ist wieder ein Frage der Frequenz/ Gesamtdurchsatz/ Nutzerzahl. Erste Ansätze liefert da aber auch schon ein Blick auf die Last der Platten. Oder einfach mal nach Betriebsschluss mit einem Client Standardvorgänge durchgehen und die Serverlast protokollieren. Aber diese Hinweise werden schon zu spekulativ. Da könnte der TE mal ein paar weitere Fakten nennen. DB Größe, Tabellenanzahl, Datenvolumen in den Tabellen, also Anzahl Records, Datentypen (manchmal werden ja ganze Filme in Datenbanken gspeichert), Anzahl Nutzer, konkrete Performance-Engpässe usw. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Hallo zusammen,
ich danke euch zunächst mal für Eure Einschätzung, die in gewisser Weise das bestätigt was ich unseren Entwicklern bzw. GL bereits mitgeteilt habe und was auch mein Verdacht ist. Man muss sich die Anwendung und die Art und Weise wie diese programmiert ist anschauen. Es handelt sich um eine Anwendung, die noch vor Kurzem via BDE angesteuert wurde und die Client-Server basiert ist, d.h. die EXE liegt zwar auf einem Fileshare im Netzwerk, wird aber lokal auf den Rechnern über eine Verknüpfung aufgerufen. Danach stellt die Anwendung eine Verbindung zur Firebird-Datenbank her. Ich persönlich bin mit meinem Latein was Optimierung betrifft mittlerweile am Ende angelangt, da ich auch bereits die verschiedensten firebird.conf Konfigurationen gefahren bin mit unterschiedlichsten Einstellungen hinsichtlich Cache usw. Hier gibt es ja verschiedenste Hinweise im Internet bzw. vorgefertigte Konfigurationsdateien, die man ausprobieren kann. Wirklich schneller wird es dadurch aber nicht! Da am Server selbst auch die gesamten Ressourcen wie CPU, RAM, Netzwerk, Festplatte mit einer minimalen Auslastung laufen, auch wenn größere Abfragen abgesetzt werden vermute ich das Bottleneck eher in der Netzwerkanbindung von Client zu Server, wobei wir hier auch durchgängig Gigabit-Anbindung mit HP-Switchen haben (Cisco wäre zwar besser, aber für die Geschwindigkeit der Anwendung sollte das nicht den wesentlichen Unterschied machen) bzw. das Bottleneck ist doch in der Anwendung zu suchen. Für weitere Diskussionen bin ich jederzeit offen! Grüße T |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Also wenn der Server überhaupt keine Last zeigt, dann ist da doch irgendwas anderes im Busch.
Sind das echte Clients? Citrix?.. Funktioniert die Namensauflösung bzw. das Routing vom Client sauber zum DB Server? Wenn z.B. jedes Paket erst mal beim lieben Gott fragen muss, wo es hin soll und wie es wieder zurück kommt, dauert das in Summe auch. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
In deiner Situation können diese Bereiche das Problem darstellen:
- der Server - das Netzwerk - der Client - die Software selbst Server und Netzwerk hast du schon ausgeschlossen. Dann schau dir den Client an. Ist der manchmal sehr unter Last? Wenn ja, was ist die Ursache? CPU? Platte? Wann ist das + was wird in der Software dann gemacht? Versuche, die Stellen in der SW zu identifizieren, an denen es hängt. Wie andere auch schon gesagt haben: Binde den Hersteller der Software ein. Ich hatte mal eine SW, die hat in regelmäßigen Abständen (1s) nachgesehen, ob es ein Update im Server gibt. War bei 2/3 Clients kein Problem. Bei 200 war das dann nicht mehr lustig. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Hier fehlt eigentlich alles was an Fakten interessant wäre :
Was für ein Fb Server : Classic-, Super- oder Superclassic auf was für einem Betriebssystem läufts Windows ? Linux ? Windows Server der auch Domaincontroller ist? Wie gross ist die DB Datei Pagesize der DB Cachepage Settings RAID, wenn ja was für eins Die IBExpert Professional Version hat einen hübschen Server Benchmark die Zahlen zum Vergleich wären mal nett mfg Hannes |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
Als Betriebssystem läuft Windows Server 2019 PageSize 16384 Datenbankgröße 21 GB Momentane firebird.conf (wobei hier schon mit verschiedenen Werten getestet wurde, auch z.B. mit TCPRemoteBufferSize mal mit hohem Wert aber auch mit kleinem Wert. ServerMode = Super DefaultDbCachePages = 100K FileSystemCacheThreshold = 2M TempBlockSize = 2M TempCacheLimit = 1000M AuthServer = Legacy_Auth, Srp, Win_Sspi AuthClient = Legacy_Auth, Srp, Win_Sspi UserManager = Legacy_UserManager, Srp TracePlugin = fbtrace WireCrypt = Enabled RemoteServicePort = 3050 RemoteBindAddress = 192.168.199.100 LockMemSize = 15M LockHashSlots = 30011 ExternalFileAccess = Full TcpRemoteBufferSize = 30000 #TcpNoNagle = 0 |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Hallo,
wenn der DB-Server sich langweilt, die App aber trotzdem (gefühlt) langsam ist, liegt es meistens an der App ... Bsp: Ein Select * From Table Where XXX füllt ein Grid und dort wurde BeginUpDate/EndUpdate (bewuss?) vergessen. Die App ist langsam, aber der DB-Server schnell ... |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Auch ein Prüfung wert: Sind die Tabellen richtig indiziert für die verwendeten Abfragen. Allerdings müssten sich, wenn die Indizierungen nicht stimmen, die Abfragen auch in der Serverbelastung - insbesondere vom Firebird-Dienst - bemerkbar machen
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Ich habe jetzt erst brandaktuell wieder so einen Fall gehabt (FIBplus-spezifisch): Funktion A arbeitet eine Schleife ab. Je Schleifendurchlauf wird ein
Delphi-Quellcode:
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.
if Dataset.RecordCountFromSrv > 0 then ...
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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? |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Wenn du Lust hast, dann sende mir doch mal hier oder per email an support@ibexpert.com 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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
:thumb:
Du hast ja sooo recht. Gruß K-H |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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 ... |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
(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 |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
Gruß K-H |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Hallo,
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Bei den Tests ist es immer die gleiche Hardware. Das ist durchgängig auf allen
Kundenservern so und auch auf unseren Rechnern. Übrigens auch mit sehr alten MSSQL Servern 2008 und früher (z.B.: W2K). Ich habe bis heute keine FB Config Parameter gefunden die daran ausser mehr als ein paar Prozent ändern. Viele kleine Abfragen sind beim FB wirklich ein Problem. Komplexe Abfragen auch auf sehr große Datenmengen sind dagegen kein Problem. Wo immer möglich setzen wir ein Query mit großer Datenmenge ein und arbeiten dann mit Locate. Das ist sehr viel schneller. Dem Kunden ist letztlich egal wieviel Speicher gebraucht wird oder was der Server macht. Der sieht nur das wir umschalten auf den MSSQL und es ist drastisch schneller. Ich bin jedenfalls froh das wir diesen etwas steingen Wege gegangen sind. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Ich würde ja gerne mal FB 4.0 ausprobieren. Weil wir aber FIBplus verwenden, ist uns dieser Weg versperrt. Es gab mal den Plan, eine Art Abstraktion auf FireDAC drauf zu setzen, die FIBplus "emuliert". Aber damit ist es ja nicht getan. Man muss schrottige Queries und Procedures anfassen. Denn selbst wenn man die rein technische Konnektivität hin bekäme, würden wohl die Vorteile von FB 4.0 verpuffen.
|
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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.zipdann 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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
Zitat:
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. |
AW: Fragen bezüglich Performance von Firebird in einer Anwendung
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. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:42 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz