Guten Tag Zusammen,
seit dem ich nun seit einer Woche das Forum hier und diverse englische durchforstet habe, wende ich mich an euch, in der Hoffnung das jemand das Verhalten kennt und im besten Fall sogar eine Lösung dazu hat.
Bei einem Kunden haben wir einen neuen Server aufgestellt und seine Softwarfe (GDI Lohn & Gehalt) umgezogen.
Die Software läuft auch einwandfrei. Zumindest auf dem Server selbst.
Sobald man über einen anderen PC versucht drauf zuzugreifen, dauern alle Abfragen (z.B. Mandantenwechsel) ca. doppelt so lange... Es ist auch nur ein einziger Anwender.
Hier eine Überdicht der Gegebenheiten:
Server: HP Server, mit Proxmox virtualisiert, 64GB RAM, SSD-Only Speicher
VM GDI: Windows Server 2022 Standard, 8GB RAM, liegt auf SSD. Außer GDI mit der Firebird Datenbank, ist nichts drauf. Da in der Einrichtungsphase, nicht mal ein Antivirus.
VM DC: Windows Server 2022 Standard, 8GB RAM, liegt auf SSD. Führt GDI aus dem Netzlaufwerk aus, also der Client ist nichts installiertes (Ist von GDI so gewollt).
PC Anwender: Windows 11, 16GB RAM, SSD. Führt GDI aus dem Netzlaufwerk aus, also der Client ist nichts installiertes.
Firebird DB: 2.5 64Bit.
Netzwerkhardware können wir ausschließen, da die zweite VM auf dem selben Host liegt und die TCP/IP Verbindungen den Server gar nicht erst verlassen.
Windows Firewall sauber freigegeben, zum Testen schon 2Tage deaktiviert gehabt.
CPU und RAM Auslastung im Schnitt bei 10%
Netzwerk nie über 15% (Auch während der Aufrufe von den Clients)
Bin inzwischen echt verzweifelt...
Gruß
Ramazan
Firebird (GDI Lohn) Aufrufe per Netzwerk halb so schnell
Moderator: thorben.braun
Das kann an 2 Dingen liegen:
a) Verbindungseinstellung.
Wird der DNS-Name oder die IP-Adresse verwendet? Bei Verwendung des DNS-Namens muss jedes mal neu die IP-Adresse ermittelt werden. Je nach Netzkonfiguration kann der Weg zum DNS-Server da schon mal dauern.
Versucht es mal direkt mit der bekannten IP.
b) Anzahl der Verbindungen.
Die Frage ist halt, wie oft Datenverkehr mit der DB aufgenommen wird um 1 Transaktion durchzuführen. Wenn für jede Abfrage immer Connect-/SQL-Aktion/Close läuft, sollte man auf jeden Fall über Connection-Pooling nachdenken.
Bei 2.5 wird ggf. der ODBC-Treiber verwendet, da ist das eine separate Einstellung.
Bei der 2.5 konnte man zwischen IP und Direkt (Messaging) die Verbindung wählen und das ist um ein vielfaches schneller. Selbst IP-Loopback über 127.0.0.1 wird von Windows intern aufgelöst und geht halt auch nicht übers Netzwerk.
Auch stellt sich generell die Frage, welche Technik für die Verbindung verwendet wird: ODBC (ist relativ alt und wird nicht weiterentwickelt), .Net oder Java. Für letzteres gibts moderne und damit auchschnellere Treiber.
Und zu guter letzt: Arbeitet ihr nun mit mehreren Usern und vorher nur mit 1 User auf der DB? Da könnt die Installationsart auf dem Server eine Rolle spielen. Super Classic ist da nicht parallel fähig. Die einfache Classic Installation (1 Prozess je Connection) hat sich da als viel effektiver erwiesen.
Hier spielt auch das DB-Caching eine Rolle, denn wenn die letzte Verbindung zugemacht wird, wird der DB-Cache gelehrt. Jede neue Verbindung muss da nun erst einige Seiten der DB immer neu laden.
Bei der FB 2.5 ist auch der Windowsfilecache nicht zu verachten, denn bevor Daten von der Platte gelesen werden, werden sie aus dem Windowsfilecache bereitgestellt, es sei denn, man hat diesen in der fireibird.conf gezielt abgeschaltet.
a) Verbindungseinstellung.
Wird der DNS-Name oder die IP-Adresse verwendet? Bei Verwendung des DNS-Namens muss jedes mal neu die IP-Adresse ermittelt werden. Je nach Netzkonfiguration kann der Weg zum DNS-Server da schon mal dauern.
Versucht es mal direkt mit der bekannten IP.
b) Anzahl der Verbindungen.
Die Frage ist halt, wie oft Datenverkehr mit der DB aufgenommen wird um 1 Transaktion durchzuführen. Wenn für jede Abfrage immer Connect-/SQL-Aktion/Close läuft, sollte man auf jeden Fall über Connection-Pooling nachdenken.
Bei 2.5 wird ggf. der ODBC-Treiber verwendet, da ist das eine separate Einstellung.
Bei der 2.5 konnte man zwischen IP und Direkt (Messaging) die Verbindung wählen und das ist um ein vielfaches schneller. Selbst IP-Loopback über 127.0.0.1 wird von Windows intern aufgelöst und geht halt auch nicht übers Netzwerk.
Auch stellt sich generell die Frage, welche Technik für die Verbindung verwendet wird: ODBC (ist relativ alt und wird nicht weiterentwickelt), .Net oder Java. Für letzteres gibts moderne und damit auchschnellere Treiber.
Und zu guter letzt: Arbeitet ihr nun mit mehreren Usern und vorher nur mit 1 User auf der DB? Da könnt die Installationsart auf dem Server eine Rolle spielen. Super Classic ist da nicht parallel fähig. Die einfache Classic Installation (1 Prozess je Connection) hat sich da als viel effektiver erwiesen.
Hier spielt auch das DB-Caching eine Rolle, denn wenn die letzte Verbindung zugemacht wird, wird der DB-Cache gelehrt. Jede neue Verbindung muss da nun erst einige Seiten der DB immer neu laden.
Bei der FB 2.5 ist auch der Windowsfilecache nicht zu verachten, denn bevor Daten von der Platte gelesen werden, werden sie aus dem Windowsfilecache bereitgestellt, es sei denn, man hat diesen in der fireibird.conf gezielt abgeschaltet.
-
martin.koeditz
- Beiträge: 467
- Registriert: Sa 31. Mär 2018, 14:35
Die GDI-Software kenne ich.
Wie ist das Netzwerk aufgebaut? Liegen Server und Client im gleichen Netz? Firebird 2.5 läuft über WAN-Strecken nicht besonders gut.
Gruß
Martin
Wie ist das Netzwerk aufgebaut? Liegen Server und Client im gleichen Netz? Firebird 2.5 läuft über WAN-Strecken nicht besonders gut.
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Die Aussage zu 2.5 kann ich nicht so stehen lassen. Im Classic-Modus (Multi Prozess) mit dem ODBC-Treiber hat die wirklich hervorragend funktioniert.
-
martin.koeditz
- Beiträge: 467
- Registriert: Sa 31. Mär 2018, 14:35
Das hängt stark von der Implementierung ab. Aber grundsätzlich hatten alle Versionen vor 3.0 starke Probleme mit der Kompression über WAN-Strecken. Hierzu gibt es auch eine offizielle Aussage seitens der Entwickler: https://www.firebirdnews.org/firebird-3 ... -benchmark
Gruß
Martin
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Da die Kommunikation ja funktioniert, ist die Freigabe zusätzlicher Ports ja nicht erforderlich. Sie ist halt nur langsamer als lokal.
Bei fehlender Firewall-Freigabe, käme ja keine Verbindung zustande.
"Führt GDI aus dem Netzlaufwerk aus, also der Client ist nichts installiertes (Ist von GDI so gewollt)."
Auch dies kann ein erheblicher Nachteil sein, je nach dem wie die Anwendung strukturiert und in welcher Sprache sie geschrieben ist.
Wenn z.B. viele Skripte/Module verwendet werden und es sich nun mal nicht um eine Web-Anwendung zu handeln scheint, müssen die Skripte halt geladen werden. Und wenn sie nicht im Spicher verbleiben, wiederholt sich das ständig.
Zu untersuchen wäre daher zumindest, ob die Sotware mit lokaler Kopie und Datenbank auf dem Server wieder genauso schnell wie vorher wird.
Wenn sowieso nur 1 User damit arbeitet, wäre hier auch das Arbeiten via RDP-Zugang vielleicht einfacher.
Bei fehlender Firewall-Freigabe, käme ja keine Verbindung zustande.
"Führt GDI aus dem Netzlaufwerk aus, also der Client ist nichts installiertes (Ist von GDI so gewollt)."
Auch dies kann ein erheblicher Nachteil sein, je nach dem wie die Anwendung strukturiert und in welcher Sprache sie geschrieben ist.
Wenn z.B. viele Skripte/Module verwendet werden und es sich nun mal nicht um eine Web-Anwendung zu handeln scheint, müssen die Skripte halt geladen werden. Und wenn sie nicht im Spicher verbleiben, wiederholt sich das ständig.
Zu untersuchen wäre daher zumindest, ob die Sotware mit lokaler Kopie und Datenbank auf dem Server wieder genauso schnell wie vorher wird.
Wenn sowieso nur 1 User damit arbeitet, wäre hier auch das Arbeiten via RDP-Zugang vielleicht einfacher.
Die FB Datenbank läuft auf virtualisiertem Storage? War das zuvor auch schon so? Anders als andere SQL-Datenbanken profitiert FB stärker von einer schnellen Platte als von viel RAM. Wobei nur 8GB für Windows und Datenbank auch schon sehr sportlich ist.
--
Joachim
Joachim
"Anders als andere SQL-Datenbanken profitiert FB stärker von einer schnellen Platte als von viel RAM".
Diese Aussage ist definitiv falsch. Je größer die DB desto mehr Ram bringt Performance, da das Lesen davon abhängig ist, wieviel Speicher ich zur Verfügung stelle.
Seit der FB 3.0 gibts ja auch echte Parallelverarbeitung. Ich habe als Cache 500.000 Seiten á 16KB definiert (default sind 2000), das macht alleine 8GB als Speicher für die DB aus, die ca. bei 70GB, wachsend, liegt. Diesen Wert habe ich mit vielen Tests herausgefunden.
Mehr bringt keinen Zuwachs in der Performance, weniger wirds wieder langsamer.
Selbst bei einer SSD ist der RAM immer noch schneller, wenn Seiten nicht geladen werden müssen.
Diese Aussage ist definitiv falsch. Je größer die DB desto mehr Ram bringt Performance, da das Lesen davon abhängig ist, wieviel Speicher ich zur Verfügung stelle.
Seit der FB 3.0 gibts ja auch echte Parallelverarbeitung. Ich habe als Cache 500.000 Seiten á 16KB definiert (default sind 2000), das macht alleine 8GB als Speicher für die DB aus, die ca. bei 70GB, wachsend, liegt. Diesen Wert habe ich mit vielen Tests herausgefunden.
Mehr bringt keinen Zuwachs in der Performance, weniger wirds wieder langsamer.
Selbst bei einer SSD ist der RAM immer noch schneller, wenn Seiten nicht geladen werden müssen.
Guten Morgen,
entschuldigt, dass ich mich nicht zurückgemeldet habe. Ich bin davon ausgegangen, ich bekomme eine Emailbenachrichtigung, wenn es neue Antworten gibt.
Alle Vermutungen Richtung Hardware und in Richtung Firebird sind falsch gewesen. Microsoft hat so viel am TCP-Stack von Windows gespielt, dass es diese massiven Verzögerungen gab. Ich denke, es liegt auch nicht an der Datenbank, sondern an den vielen kleinen Dateien, die beim Mandantenwechsel mit übertragen werden...
Meine Lösung (Sowohl am Server 2022 und am Client Windows 11 ausgeführt)
Powershell Skript mit Adminrechten ausführen
https://github.com/MysticFoxDE/WINDOWS- ... ZATION.ps1
Wird sind beim Mandantenwechsel von 10-11 Sekunden auf annehmbare 3 Sekunden runter!!!
Vielleicht hilft das dem einen oder anderen!
Gruß
Ramazan
entschuldigt, dass ich mich nicht zurückgemeldet habe. Ich bin davon ausgegangen, ich bekomme eine Emailbenachrichtigung, wenn es neue Antworten gibt.
Alle Vermutungen Richtung Hardware und in Richtung Firebird sind falsch gewesen. Microsoft hat so viel am TCP-Stack von Windows gespielt, dass es diese massiven Verzögerungen gab. Ich denke, es liegt auch nicht an der Datenbank, sondern an den vielen kleinen Dateien, die beim Mandantenwechsel mit übertragen werden...
Meine Lösung (Sowohl am Server 2022 und am Client Windows 11 ausgeführt)
Powershell Skript mit Adminrechten ausführen
https://github.com/MysticFoxDE/WINDOWS- ... ZATION.ps1
Wird sind beim Mandantenwechsel von 10-11 Sekunden auf annehmbare 3 Sekunden runter!!!
Vielleicht hilft das dem einen oder anderen!
Gruß
Ramazan