Fragen bezüglich Performance von Firebird in einer Anwendung

[Codehunter]

Zitat von jobo:

Datenbank Tuning durch einen Fachmann kann in der Situation schon hilfreich sein. Es kommt halt drauf an.

Richtig. Da muss man sich immer den Einzelfall anschauen. Ich wäre jedenfalls sehr daran interessiert, sollte durch Einstellungen am DB-Server das beschriebene Problembild sich wesentlich verbessern. Denn die Problemlage ist mir bei unserer DB sehr vertraut.

[TK8782]

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

[jobo]

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.

[TigerLilly]

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.

[Codehunter]

Zitat von TK8782:

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.

Zitat von TK8782:

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?

Zitat von TK8782:

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?

Zitat von TK8782:

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.

[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