Frage: 🐌🐌🐌JTL-Wawi 1.9 - Wie schnell öffnet sich bei euch die Auftragsansicht?

[NoOne]

Hi,

wir haben auch das Problem, dass die Artikelverwaltung und Auftragverwaltung sehr träge ist.

Unser lokaler Server schaut wie folgt aus:

HPE ProLiant ML350 GEN10
Windows Server 2022 Datacenter
Intel Xeon(R) Silver 4210 CPU @ 2,20 Ghz - 2.19 GHz (2 Prozessoren) insgesamt 20 Kerne
320 GB RAM DDR4
1.92 TB 6G SATA SSD


Der Client wie folgt:

Intel i9-10900K
64 GB RAM DDR4
Samsung PRO 990 4 TB
Windows PRO 11

An der Hardware kann es nicht liegen, dass die Zugriffszeiten sehr sehr langsam sind und teilweise stark hängen.

Ich bin ratlos, was ich noch machen (kaufen) müsste das ich eine Echtzeit bearbeitung haben kann.

Client ist per LAN verbunden.

Hat sonst noch jemand solche Probleme?

LG.

Es lässt sich schlecht verallgemeinern, aber: Intel war der erste Fehler beim Server, 6G SATA der zweite. Ein AMD Epyc ist nicht nur energieeffizienter, sondern einem Xeon in allem außer der Single-Core Leistung überlegen. SSD an einem 6G SATA Anschluss bringt max. 600 MB/s. Das ist gut gegenüber HDDs, aber schlecht gegenüber SSDs auf NVM.2 oder PCIe Basis. 20 Cores außerdem leicht zu wenig. MSSQL kann 4 CPUs oder 24 Cores nutzen (mein ich). 32 Cores wären also nicht schlecht. 24 für MSSQL, 8 für alles andere.

Ein gutes Systemhaus wird dich da allerdings vermutlich besser beraten können als die meisten aus der Community und ich. Das sollte aber am besten eins sein, das mit Intel und AMD Erfahrung hat. Aus Gewohnheit auf Intel zu setzen, geht schon mal nach hinten los.

 

[ChrisTS]

Es lässt sich schlecht verallgemeinern, aber: Intel war der erste Fehler beim Server, 6G SATA der zweite. Ein AMD Epyc ist nicht nur energieeffizienter, sondern einem Xeon in allem außer der Single-Core Leistung überlegen. SSD an einem 6G SATA Anschluss bringt max. 600 MB/s. Das ist gut gegenüber HDDs, aber schlecht gegenüber SSDs auf NVM.2 oder PCIe Basis. 20 Cores außerdem leicht zu wenig. MSSQL kann 4 CPUs oder 24 Cores nutzen (mein ich). 32 Cores wären also nicht schlecht. 24 für MSSQL, 8 für alles andere.

Ein gutes Systemhaus wird dich da allerdings vermutlich besser beraten können als die meisten aus der Community und ich. Das sollte aber am besten eins sein, das mit Intel und AMD Erfahrung hat. Aus Gewohnheit auf Intel zu setzen, geht schon mal nach hinten los.

Nur liegt das Problem sicher nicht am Server. Wir haben eine 15.000 Euro teuren DELL Serve, betreut von einem der fähigsten Mitarbeiter von JTL und beim erstellen von Variationswert- und Namen sowie etlichen anderen Funktionen hangt sich die Wawi seit dem Update von 1.5 auf 1.9 total auf.

Man muss ja nur aml im Taskmanager schauen und sieht dann sofort, dass sich die Wawi bei jedem öffnen eines Auftrags immer noch mehr Arbeitsspeicher zieht.
Das ist definitiv kein Serverproblem und das sollte man auch niemanden einreden!

 

[NoOne]

Nur liegt das Problem sicher nicht am Server. Wir haben eine 15.000 Euro teuren DELL Serve, betreut von einem der fähigsten Mitarbeiter von JTL und beim erstellen von Variationswert- und Namen sowie etlichen anderen Funktionen hangt sich die Wawi seit dem Update von 1.5 auf 1.9 total auf.

Man muss ja nur aml im Taskmanager schauen und sieht dann sofort, dass sich die Wawi bei jedem öffnen eines Auftrags immer noch mehr Arbeitsspeicher zieht.
Das ist definitiv kein Serverproblem und das sollte man auch niemanden einreden!

Und deine Datenbank ist wie groß?

 

[intrinsicforce]

[...] SSD an einem 6G SATA Anschluss bringt max. 600 MB/s. [...]

Die Frage wäre ja eher: Würde bei einer 10 - 100 GB großen JTL-Datenbank eine schnellere Lese bzw. Übertragungsrate der SSD überhaupt noch einen messbaren Vorteil bringen? Ich behaupte mal, dass das nicht der Fall ist.

 

[ChrisTS]

Die Frage wäre ja eher: Würde bei einer 10 - 100 GB großen JTL-Datenbank eine schnellere Lese bzw. Übertragungsrate der SSD überhaupt noch einen messbaren Vorteil bringen? Ich behaupte mal, dass das nicht der Fall ist.

Das hat auch ganz sicher nichts mit der Datenbank Größe zu tun (16gb bei mir aber auch schon fast gleich viel mit der 1.5).
Schaut euch einfach mal den Taskmanager auf dem Client an und nennt mir ein Datenbank basiertes Programm das so Arbeitsspeicher frisst wie die neue Wawi 😂🙈

 

[versuchsmal]

Das Problem ist die 1.9 Sie ist und bleibt träge. Alle die vorher auf der 1.5 waren und sind auf die 1.9 gewechselt sollten das Problem kennen. Mit der Auftragsmaske ist ja nun auch nicht neu, dafür gibt ja Seitenweise lesestoff.

 

[mh1]

Nur liegt das Problem sicher nicht am Server. Wir haben eine 15.000 Euro teuren DELL Serve, betreut von einem der fähigsten Mitarbeiter von JTL

kurze Zwischenfrage:
im oberen Post hast du geschrieben, dass ihr einen lokalen Server im selben Lan wie der Client habt.
Aber wenn du sagst, dass der Server von JTL betreut wird, ist es dann doch ein Managed Server, der im Internet steht?

 

[ChrisTS]

kurze Zwischenfrage:
im oberen Post hast du geschrieben, dass ihr einen lokalen Server im selben Lan wie der Client habt.
Aber wenn du sagst, dass der Server von JTL betreut wird, ist es dann doch ein Managed Server, der im Internet steht?

Der Server steht bei uns im Haus und die monatliche Wartung macht ein Programmierer der bei JTL arbeitet und zusätzlich eine Gewerbe hat um Kunden wie uns zu betreuen

 

[mh1]

Der Server steht bei uns im Haus und die monatliche Wartung macht ein Programmierer der bei JTL arbeitet und zusätzlich eine Gewerbe hat um Kunden wie uns zu betreuen

Ah, verstehe. Dann kann man ja also davon ausgehen, dass der SQL-Server gut eingerichtet ist.
Aber ich würde auch mal behaupten, dass du das von dir erhoffte Ziel, eine Bearbeitung in Echtzeit, mit JTL nie erreichen wirst.

 

[ChrisTS]

Ah, verstehe. Dann kann man ja also davon ausgehen, dass der SQL-Server gut eingerichtet ist.
Aber ich würde auch mal behaupten, dass du das von dir erhoffte Ziel, eine Bearbeitung in Echtzeit, mit JTL nie erreichen wirst.

Eine Bearbeitung in Echtzeit habe ich nie erwartet. Mir würde es reichen, mann kann wieder so arbeiten wie vor der 1.0 oder so wie mit der 1.5
Die 1.9 ist hier nicht akzeptabel und der Fehler ist deutlichst nachstellbar (Reservierung Arbeitsspeicher).

 

[mh1]

Eine Bearbeitung in Echtzeit habe ich nie erwartet.

Okay - sorry, ich bin mit den Beitragsschreibern durcheinandergekommen, weil er hier hatte das geschrieben:

Ich bin ratlos, was ich noch machen (kaufen) müsste das ich eine Echtzeit bearbeitung haben kann.

...und ich dachte, er wollte Ratschläge für mögliche Stellschrauben.

 

[no80]

Das hat mit der Datenbank selbst nicht so viel zu tun.
Ich habe in meinem Netzwerk über 25 Clients.
Gerade an 2 getestet:
An meinem, HP EliteDesk 800 G3, Windows 11, mit Admin-Rechten, SSMS laufend, ODBC 17, usw. - definitiv unter 2 Sekunden, eher weniger.
und an gerade neu aufgesetzten Windows 11, 800 G4, aber mit ausprobieren: mit .NET 3.5, ohne, als Admin, als normaler Benutzer aber in JTL-Ordner mit Schreibrechten,
mit Sharp-WaWi, mit Standard-WaWi, und jeweils Neustart - das Endergebnis - definitiv immer über 2 Sekunden, eher 3-4.

Konntest du was ändern ?
Bei uns sind auch „ältere“ User zu lahm!
Mit den Admin geht’s immer schnell bzw schneller.
Egal zu welches Tageszeit.

 

[mvh]

Konntest du was ändern ?
Bei uns sind auch „ältere“ User zu lahm!
Mit den Admin geht’s immer schnell bzw schneller.
Egal zu welches Tageszeit.

Ändern - Nein, aber es beschwert sich keiner, es dauert auch ca. 3 Sekunden.
Wir sind mittlerweile bei 1.9.5 bzw. 1.9.6 (im Test) angekommen.
1.9.5.4 (Sharp oder Alter Kern) ca. 3 Sekunden, egal ob Admin oder normaler User.
1.9.6.5 (Sharp ) ca. 2 Sekunden, (Alter Kern) ca. 3 Sekunden, egal ob Admin oder normaler User.
Wir haben SQL Server 2022 im lokalen Netzwerk + WIN11-Rechner