Fragen bezüglich Performance von Firebird in einer Anwendung

[hstreicher]

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

[TK8782]

Zitat von hstreicher:

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

Die Datenbank ist als Superserver installiert.
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

[hoika]

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

[kretabiker]

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

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