Performance lokaler Client

[Boyshoe]

Hallo,
ich nutze seit 8 Monaten JTL und habe eine allgemeine Frage zur Performance.
Meine Datenbank liegt bei Ecomdata. Hier greifen 3 Leute/RDP Benutzer auf diese Datenbank zu. Wawi Clienten sind auch auf dem Server.
Ich persönlich würde lieber mit einem lokal installierten Clienten auf die Datenbank zugreifen, die Performance ist so aber deutlich schlechter.

Die Frage ist, warum?

Ist das hauptsächlich ein Verbindungs-Ding, liegt das an der Hardware des eingesetzten Rechners oder ist es eine Mischung aus beidem?
Ich nutze hier einen 5 Jahre alten Ryzen 5 Prozessor mit 16 GB Ram, der ansonsten ausreichend schnell für mich ist.
Könnte ich in Bezug auf die Wawi mit einem Prozessor Upgrade und/oder 32/64GB Ram noch einiges rausholen?

Danke und Grüße

 

[Daniel1]

Das liegt daran, dass Wawi serverseitig rein SQL-basiert ist und dadurch die Clients alle direkt mit dem SQL-Server kommunizieren müssen. SQL ist sehr latenzempfindlich, und für die meisten Aktionen braucht es mehrere Abfragen. Und da die Latenz übers Internet im Vergleich zu einem LAN um ein vielfaches höher ist, macht sich das einfach direkt bemerkbar.
Diese Architektur, serverseitig nur auf SQL zu setzen, ist aus diesen und diversen anderen Gründen auch ziemlich ungewöhnlich (zumindest bei moderner Software). In der Regel hat man serverseitig einen Prozess laufen der die Business-Logik usw. übernimmt, und die Clients kommunizieren dann z. B. über REST mit diesem. Ich hoffe mal, dass das bei JTL für die Zukunft auch irgendwann mal geplant ist.

Das ist auch der Grund, weshalb bei Wawi so oft auf RDP-Lösungen gesetzt wird, da das eigentlich die einzige Möglichkeit ist, dieses Problem zu umgehen.

 

[mh1]

Das ist auch der Grund, weshalb bei Wawi so oft auf RDP-Lösungen gesetzt wird, da das eigentlich die einzige Möglichkeit ist, dieses Problem zu umgehen.

Naja, ob es die einzige Möglichkeit ist.... 🤔
Das Thema der Latenzen im Internet könnt man z.b. auch komplett übergehen, indem man denn SQL-Server ins LAN holt 🤔

 

[Daniel1]

Naja, ob es die einzige Möglichkeit ist.... 🤔
Das Thema der Latenzen im Internet könnt man z.b. auch komplett übergehen, indem man denn SQL-Server ins LAN holt 🤔

Klar, ich meinte jetzt, so lange der Server nicht lokal steht. Und auch dann hat man das Problem ja wieder, sobald jemand von außerhalb zugreifen muss.

 

[Svenka]

Naja, ob es die einzige Möglichkeit ist.... 🤔
Das Thema der Latenzen im Internet könnt man z.b. auch komplett übergehen, indem man denn SQL-Server ins LAN holt 🤔

Wie machst du das denn mit mehreren Standorten?

 

[FOC Solutions]

Noch ein weiterer Gedanke, sind die Clients per LAN oder WLAN mit dem Internet verbunden? WLAN hat deutlich höhere Latenzen und verschlimmert das Problem noch einmal deutlich.

 

[Alex_adv]

Namd!
Wir greifen seit Anbeginn mit lokalen Clients von allen möglichen Orten auf unser JTL, DB ist bei einem Dienstleister gehostet, zu. Das war bis zu Version 1.9.6.5 auch mit guter (jetzt nicht superguter) Performance möglich, ein flüssiges Arbeiten, gerade in der Faktura war durchaus möglich.
Seit unserem Update vor 4 Wochen auf V 1.11.3 ist ein regelrechter Zusammenbruch der Geschwindigkeit festzustellen, besonders beim Wechsel in noch nicht aufgerufene Bereiche, also z.B. vom Artikelstamm in den Verkauf, oder von da zu Beschaffung usw. müssen wir nun, statt wie bisher 5 Sekunden, bis zu einer Minute(!!) warten. Wenn man einmal reingewechselt ist, ist der nächste Wechsel wieder gewohnt zügig, aber gerade nach Neustart von JTL ist das ein wiederkehrendes Ärgernis.
Was auch seit dem Update auf 1.11.3 neu ist, dass die Seitenvorschau im Prinzip nicht mehr verwendbar ist, da nahezu jede Vorschau JTL ohne jede Meldung abstürzen lässt. Ein Kollege hat sich mal die Mühe gemacht, und festgestellt, dass er regelmäßig nach 3 JTL-Abstürzen 1 x die Druck-Vorschau zu sehen bekommt..... Aber ich bitte Euch.
Wenn Terminal-Server künftig die einzige Möglichkeit sein soll, JTL in erträglicher Geschwindigkeit zu nutzen, na dann Gute Nacht, haben ja in den letzten Monaten noch nicht genug Kostenexplosionen gehabt....
Im Übrigen greifen wir mit verschiedensten Tools (meist lesend) per ODBC auf die Datenbank auf dem Server zu, ein Performance-Problem haben wir da an keiner Stelle.
Insofern ist es uns besonders rätselhaft, was da so lange dauert, und wieso das erst in den aktuellen Versionen so ist. Vielleicht kann ja hier mal ein JTL-Programmierer Licht ins Dunkel bringen.

Gruß

 

[recent.digital]

Ähnliches hier:

https://forum.jtl-software.de/threa...eu-eingerichtetem-pc-remote-datenbank.243711/

Habt ihr schon einen Vorgang bei JTL aufgemacht?

 

[Boyshoe]

Ob sich die Geschwindigkeit jetzt grundlegend verschlechtert hat, kann ich nicht sagen, da ich noch nicht lang genug dabei bin und meistens auf dem Server arbeite.
Ich habe jetzt aber testweise lokal auf 2 Rechnern gearbeitet.....meinem Ryzen 5 mit 16GB Ram und einem neuen Intel 3 mit 8 GB Ram.
Beide sind deutlich langsamer als der Server, aber der Ryzen5 ist gefühlt doppelt so schnell wie der Intel 3.

Daher noch einmal die Frage? Liegt das am Prozessor, am Ram, oder beidem und könnte ich mit einem (Prozessor/Ram) Upgrade noch etwas herausholen?
Irgendwo ist ja wahrscheinlich die Fahnenstange erreicht (vielleicht schon mit dem Ryzen5 und 16GB Ram?) und es würden auch z.b. 128GB Ram nichts mehr bringen.

 

[Daniel1]

Ob sich die Geschwindigkeit jetzt grundlegend verschlechtert hat, kann ich nicht sagen, da ich noch nicht lang genug dabei bin und meistens auf dem Server arbeite.
Ich habe jetzt aber testweise lokal auf 2 Rechnern gearbeitet.....meinem Ryzen 5 mit 16GB Ram und einem neuen Intel 3 mit 8 GB Ram.
Beide sind deutlich langsamer als der Server, aber der Ryzen5 ist gefühlt doppelt so schnell wie der Intel 3.

Daher noch einmal die Frage? Liegt das am Prozessor, am Ram, oder beidem und könnte ich mit einem (Prozessor/Ram) Upgrade noch etwas herausholen?
Irgendwo ist ja wahrscheinlich die Fahnenstange erreicht (vielleicht schon mit dem Ryzen5 und 16GB Ram?) und es würden auch z.b. 128GB Ram nichts mehr bringen.

Mit Hardware-Upgrades am Client wirst du da kaum eine Verbesserung rausholen. Gut, 8 GB RAM sind heute schon etwas knapp, da könnten 16 GB eventuell etwas performanter sein. Aber mehr als 16 GB werden dir kaum eine Verbesserung bringen, außer du hast parallel sehr RAM-intensive Anwendungen laufen.
Auch beim Prozessor glaub ich kaum, dass ein Upgrade dir hier viel bringen würde. Warum der Rechner mit dem i3 so viel langsamer ist, schwer zu sagen. Was für ein i3 ist das denn, und was für ein Ryzen 5? Sind beide netzwerktechnisch gleich angeschlossen? Verkabelt oder WLAN?

 

[sebjo82]

Wie machst du das denn mit mehreren Standorten?

VPN

 

[Boyshoe]

Mit Hardware-Upgrades am Client wirst du da kaum eine Verbesserung rausholen. Gut, 8 GB RAM sind heute schon etwas knapp, da könnten 16 GB eventuell etwas performanter sein. Aber mehr als 16 GB werden dir kaum eine Verbesserung bringen, außer du hast parallel sehr RAM-intensive Anwendungen laufen.
Auch beim Prozessor glaub ich kaum, dass ein Upgrade dir hier viel bringen würde. Warum der Rechner mit dem i3 so viel langsamer ist, schwer zu sagen. Was für ein i3 ist das denn, und was für ein Ryzen 5? Sind beide netzwerktechnisch gleich angeschlossen? Verkabelt oder WLAN?

Das ist einmal ein i3-14100T Prozessor und ein Ryzen 5 Pro 5650U. Vom Papier her tun die sich nicht viel...

 

[Daniel1]

Das ist einmal ein i3-14100T Prozessor und ein Ryzen 5 Pro 5650U. Vom Papier her tun die sich nicht viel...

Die tun sich tatsächlich nicht viel, der Intel ist von der Single Thread Leistung her sogar etwas besser. Wie gesagt, falls der Rechner durch die 8 GB RAM vielleicht etwas ausgebremst wird, könnte ein Upgrade auf 16 GB etwas bringen, aber Wunder sollte man da nicht erwarten.

Der Flaschenhals bleibt hier SQL übers Internet (da eben oft viele aufeinanderfolgende Abfragen notwendig sind). Das ist auch der Grund, warum ecom RDP überhaupt anbietet. Falls du WLAN verwendest, könnte ein Umstieg auf eine kabelgebundene Verbindung noch eine Verbesserung bringen.
Falls über die Internetverbindung noch einiger anderer Traffic läuft (Downloads, Streaming etc.), kann auch das die Performance von JTL negativ beeinflussen. In dem Fall könnte QoS auf dem Router helfen.
Du könntest auf den Rechnern jeweils mal den JTL-Server pingen und das Ergebnis hier posten.

 

[Svenka]

VPN

Schon klar, mir ging es darum das eben nicht jeder den Server ins LAN stellen kann der Performanceprobleme hat. Sobald du mehrere Standorte hast musst du übers Internet - außer du lässt eine eigene Leitung verbuddeln natürlich.

 

[sebjo82]

Schon klar, mir ging es darum das eben nicht jeder den Server ins LAN stellen kann der Performanceprobleme hat. Sobald du mehrere Standorte hast musst du übers Internet - außer du lässt eine eigene Leitung verbuddeln natürlich.

VPN + RDP
Das ist die einzige Lösung
Alles andere ist zu lahm

 

[Daniel1]

Ich hoffe wirklich, dass JTL irgendwann auf eine Architektur umsteigt, die eine gute Performance ermöglicht, ohne auf RDP als Krücke angewiesen zu sein. Man hat heute einfach sehr oft die Situation, dass der Server nicht lokal in der Firma steht. Und selbst wenn der Server in der Firma steht, hat man fast immer die Situation, dass auch von extern zugegriffen werden muss, sei es durch mehrere Standorte, Homeoffice, Außendienst oder was auch immer. Vielleicht ja mit JTL 2.0, dass ja, wie man hört, bald kommen soll.

 

[ergowebshop]

.. Das war bis zu Version 1.9.6.5 auch mit guter (jetzt nicht superguter) Performance möglich, ein flüssiges Arbeiten, gerade in der Faktura war durchaus möglich...
Seit unserem Update vor 4 Wochen auf V 1.11.3 ist ein regelrechter Zusammenbruch der Geschwindigkeit festzustellen, besonders beim Wechsel in noch nicht aufgerufene Bereiche, also z.B. vom Artikelstamm in den Verkauf, oder von da zu Beschaffung usw. müssen wir nun, statt wie bisher 5 Sekunden, bis zu einer Minute(!!) warten. Wenn man einmal reingewechselt ist, ist der nächste Wechsel wieder gewohnt zügig, aber gerade nach Neustart von JTL ist das ein wiederkehrendes Ärgernis.

Dann kennst du wohl nicht die Zeit dazwischen, wo man parallel die alte Oberfläche oder die neue nutzen konnte.
In der alten Version lädt die Wawi beim Start alle Menüpunkte (grundlegender Aufbau, Benutzereinstellungen etc.), das hat den Start der Wawi langsam gemacht aber dann lief es.
Mit der neuen Oberfläche wollte man den Start beschleunigen indem es nur den ersten Menüpunkt lädt (z.B. Dashboard), das erste mal seit Start auf Verkauf/Artikel etc. zu gehen lädt dann diese Menüs nach, danach laufen die aus dem RAM. Und beim nächsten Wawi Start das selbe Spiel.
Den Umstand haben wir jetzt alle.

 

[Alex_adv]

Ah, okay. Die Intention dahinter erscheint mir logisch. Wenigstens habe ich jetzt eine Erklärung für das "neue" Verhalten. Das Doofe dabei ist: Dass der Neustart nunmehr statt 90 Sekunden schon in 40 Sekunden passiert, fällt nicht so sehr auf, wie das extrem zähe Umschalten zwischen den Hauptbereichen. Aber wir haben uns schon fast daran gewöhnt.

Nur das Thema mit der Druckvorschau, dass die mittlerweile nicht mehr nutzbar ist, das kann doch nicht so bleiben.
Wir drucken in unserer Verzweiflung nun lieber in PDF-Drucker, wenn wir mal einen Druck checken müssen. Weil: Druckvorschau = in 90% aller Fälle: JTL-Absturz!

 

[ergowebshop]

Weil: Druckvorschau = in 90% aller Fälle: JTL-Absturz!

Also von 1.9 auf 1.11 ist schon sportlich. Könnt Ihr die Druckvorlagen bearbeiten? Es sollte dann eigentlich meckern wenn z.B. irgendeine Variable nicht gefunden wird (gibt es nicht mehr oder heißt plötzlich anders), auch wenn die Vorlagen Datenbankabfragen machen (weil irgendwann etwas gebastelt wurde was serienmäßig nicht ging). Kann auch irgendwas ausgeblendetes oder außerhalb des Druckbereich sein, dann geht PDF aber physischer Drucker nicht.
Ein Indiz dafür wäre eine Vorlage zu testen die ihr gar nicht nutzt, z.B. rechtsklick auf ein Artikel und "Artikelettiketten drucken" > Druckvorschau, funktioniert die?

 

[Alex_adv]

@ergowebshop :
hast Recht, danke für den Ansatz, wir werden das beobachten. Interessanterweise machen die eigentlichen Drucke und Druck in PDF keine Zicken. Nur die Vorschau. Spanned ist auch: wenn sie denn mal angezeigt wird, dann immer zweimal!!!
Wenn das Fehlerbild natürlich keiner von euch so kennt, hat es wohl nichts mit der neuen JTL-Version zu tun.... ist noch sehr mystisch.