AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Fragen bezüglich Performance von Firebird in einer Anwendung

Fragen bezüglich Performance von Firebird in einer Anwendung

Ein Thema von TK8782 · begonnen am 8. Aug 2019 · letzter Beitrag vom 15. Aug 2019
Antwort Antwort
Seite 2 von 8     12 34     Letzte » 
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 10:11
Es handelt sich um eine Anwendung, die noch vor Kurzem via BDE angesteuert wurde und die Client-Server basiert ist
Da wäre doch mal interessant, welche Konnektoren verwendet wurden. Ich habe mal eine Testanwendung erstellt und mit verschiedenen Konnektoren (FIBplus, FireDAC, ZEOS und UniDAC) darauf zugegriffen. Bei identischen Queries war FIBplus am schnellsten, FireDAC dicht dahinter, dann lange nichts und dann ZEOS gefolgt von UniDAC. Wobei UniDAC bei Random-Select-Update-Pingpong mehr als doppelt so lang brauchte wie FIBplus.

die EXE liegt zwar auf einem Fileshare im Netzwerk, wird aber lokal auf den Rechnern über eine Verknüpfung aufgerufen.
Wird die Anwendung tatsächlich lokal aufgerufen oder ist das ein Terminalserver oder Citrix oder sowas?

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
Wurde denn so ein Benchmark auch am alten Server gemacht bevor der neue in Betrieb ging?

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)
Das ist nur wieder Ferrari vs. Mercedes SLK. Mehr Geschmackssache als technisch relevant. Es gibt aber auch 100-Euro-Rackswitches, die tatsächlich nur eine 64 Einträge große MAC-Table haben und mehr mit ARP Discovery als Pakettransport beschäftigt sind. Sowas sollte man meiden.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
hstreicher

Registriert seit: 21. Nov 2009
220 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#12

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 12:30
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
  Mit Zitat antworten Zitat
TK8782

Registriert seit: 14. Jun 2019
9 Beiträge
 
#13

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 13:49
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
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.269 Beiträge
 
Delphi 10.4 Sydney
 
#14

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 14:25
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 ...
Heiko
  Mit Zitat antworten Zitat
kretabiker

Registriert seit: 10. Mär 2005
Ort: Bargteheide
183 Beiträge
 
Delphi 11 Alexandria
 
#15

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 15:20
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
Udo Treichel
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 16:57
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
kretabiker

Registriert seit: 10. Mär 2005
Ort: Bargteheide
183 Beiträge
 
Delphi 11 Alexandria
 
#17

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 17:10
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?
Udo Treichel
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#18

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 19:06
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.
Gruß, Jo
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#19

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 8. Aug 2019, 19:11
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
642 Beiträge
 
FreePascal / Lazarus
 
#20

AW: Fragen bezüglich Performance von Firebird in einer Anwendung

  Alt 10. Aug 2019, 00:18
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.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:54 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