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

[Powalowski]

12 Cores sagt ja erstmal nicht viel, solange Du nicht sagst, ob das Core-I oder Xeons und welche Generation
Was für ein SQL Server? Express oder Standard und welches OS darunter.
Was für Festplatten?

Unabhängig von den Details halte ich 16GB für sehr, sehr, sehr wenig RAM

Deine 1-2 Sekunden hast Du dann direkt auf dem Server gemessen?
Wie? Direkt nach dem Wawi Start oder nachdem bereits schonmal ein anderer Auftrag geöffnet worden ist?


Nachtrag.
Ich hab mal eben direkt auf dem Server bei uns probiert.
Wawi 1.8, gefühlt im unteren 2 Sekunden Bereich.
Die Ursache dafür muss nicht unbedingt auf SQL Ebene liegen. Das Fenster, das da in DotNet geladen wird, hat eine sehr große Menge an Steuerlemente. Die laden dauert.

Danke!
2 Sekunden OMG, gleiche Katastrophe
16 Core AMD CPU von 2022 mit insg. 128gb ECC Ram, NVME SSDs auf ZFS 7.2 mit Overlayfs im Docker.
Das Setup muss akzeptabel sein, das müsste ja sogar auf schlechterer Hardware ordentlich laufen.

Aus meiner Sicht scheint die Datenbank zu flutschen, siehe letzten Post, da hab ich die Timings reingestellt.
Vom ersten, bis zum letzten Query 283ms

Da fragt man sich, was in den anderen 2,5Sekunden passiert.

Bevor wieder alle Fragen: Ja, mit beiden EXEN

 

[John]

Das ist nur eine Vermutung.

Mit der 1.5 war der Auftrag Bestandteil des "Hauptfensters". Ich vermute, die Steuerelemente wurden einmal geladen und danach nur versteckt, wenn man in einen anderen Bereich gewechselt ist.

Mit > 1.6 ist der Auftrag ein eigenes Fenster (Form), welches beim Öffnen jedes mal neu erstellt wird. Das braucht Zeit.
Dafür gibts den Vorteil, gleichzeitig mehrere Aufträge in eigenen Fenstern offen haben zu können.

 

[littled]

Ich arbeite nur im Hintergrund und selten in der WaWi aber ich sehe bei unseren Mitarbeitern wie langsam jede Aktion ausgeführt wird. Ich hab mich eben mal eingeloggt, alleine schon oben den Reiter zu wechseln dauert über 2,5 Sekunden. Wenn ich einen Auftrag öffne sind es ca. 2 Sekunden. Und das ist unser normal Zustand der heute erst wieder erreicht wurde.
Letzte Woche hatten wir auf 1.9.4.5 geupdated und danach lief gar nichts mehr normal. JTL Support rät uns die Einstellungen aus dem JTL Diag Tool zu übernehmen oder einen externen SQL Admin zu beauftragen um alles zu optimieren. So eine Antwort nachdem man seit 7 Jahren Kunde ist, ist schon schade.

 

[Powalowski]

Das ist nur eine Vermutung.

Mit der 1.5 war der Auftrag Bestandteil des "Hauptfensters". Ich vermute, die Steuerelemente wurden einmal geladen und danach nur versteckt, wenn man in einen anderen Bereich gewechselt ist.

Mit > 1.6 ist der Auftrag ein eigenes Fenster (Form), welches beim Öffnen jedes mal neu erstellt wird. Das braucht Zeit.
Dafür gibts den Vorteil, gleichzeitig mehrere Aufträge in eigenen Fenstern offen haben zu können.

Egal wie man es dreht und wendet, jede mittelgite Webapp schafft es so einen Datensatz in unter 500ms zu liefern, dann sollte ja eine native Anwendung dazu in der Lage sein.

 

[Powalowski]

Ich arbeite nur im Hintergrund und selten in der WaWi aber ich sehe bei unseren Mitarbeitern wie langsam jede Aktion ausgeführt wird. Ich hab mich eben mal eingeloggt, alleine schon oben den Reiter zu wechseln dauert über 2,5 Sekunden. Wenn ich einen Auftrag öffne sind es ca. 2 Sekunden. Und das ist unser normal Zustand der heute erst wieder erreicht wurde.
Letzte Woche hatten wir auf 1.9.4.5 geupdated und danach lief gar nichts mehr normal. JTL Support rät uns die Einstellungen aus dem JTL Diag Tool zu übernehmen oder einen externen SQL Admin zu beauftragen um alles zu optimieren. So eine Antwort nachdem man seit 7 Jahren Kunde ist, ist schon schade.

Wahnsinn. Ich versichere dir, bis mich einer vom Gegenteil überzeugt: Welche heilige Konfiguration soll denn mal eben Faktor 10 Beschleunigung bringen? Dann wäre ja auch der ganze SQL Server kompletter Schrott, wenn es eine heilige Konfiguration gäbe.
Ich habs gemessen: Bei uns braucht die Wawi unter 300ms für die Queries beim öffnen der Auftragsbearbeitung. Die restlichen 2,5 Sekunden sind ein Bug.

Miss die Queries und erstell ein Ticket 👍🏻

 

[recent.digital]

Die 1.9.4.6 enthält einige Performance Verbesserungen - das könnte ggf. etwas Abhilfe schaffen.

 

[Powalowski]

Die 1.9.4.6 enthält einige Performance Verbesserungen - das könnte ggf. etwas Abhilfe schaffen.

Da steht nichts von Auftragsbearbeitung bei den Performance-Verbesserungen. Wir warten auf Rückmeldung zu unserem Ticket.
Leute, bitte erstellt auch Tickets, wenn wir da nichts melden, dann denken alle es sei ok, dass die Auftragsbearbeitung mal eben 2Sek+ zum Öffnen braucht

 

[mvh]

Moin.
Probiere mal diese Befehle (ist ein Update von Microsoft Visual C++ 2015-2022 Redistributable) aus:
winget upgrade Microsoft.VCRedist.2015+.x86
winget upgrade Microsoft.VCRedist.2015+.x64
Und nach einem Neustart, bitte die Leistung zu messen.
Ihr MVH-Team

 

[Powalowski]

Immer noch über 2 Sek, hat nicht geholfen.
Version 14.40.33810

 

[intrinsicforce]

Hat jemand mal gemessen bei JTL-gehosteter DB?

 

[mvh]

Hat jemand mal gemessen bei JTL-gehosteter DB?

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.

 

[Powalowski]

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.

Also ein Bug in der Anwendung selbst, jetzt muss JTL ran!

 

[mvh]

Also ein Bug in der Anwendung selbst, jetzt muss JTL ran!

Ein Bug oder Programmfehler ist eine nicht geplante Abweichung von der Anwendungslogik. Eine Verzögerung von 1-1.5 Sekunden ist eine tollerierbare Leistungsminderung. Und diese werden nicht mit höheren Prioritäten behandelt. Und manche von uns warten seit Jahren auf bestimmte Tickets.

 

[littled]

Die 1.9.4.6 enthält einige Performance Verbesserungen - das könnte ggf. etwas Abhilfe schaffen.

Das sollte die 1.9.4.5 auch bringen, sie hat aber nur für sehr viel Frust bei unseren Mitarbeitern gesorgt.

Ein Bug oder Programmfehler ist eine nicht geplante Abweichung von der Anwendungslogik. Eine Verzögerung von 1-1.5 Sekunden ist eine tollerierbare Leistungsminderung. Und diese werden nicht mit höheren Prioritäten behandelt. Und manche von uns warten seit Jahren auf bestimmte Tickets.

Ich habe die beiden Pakete welche du Vorgeschlagen hast installiert. Leider hat es nicht geholfen. Der erste Auftrag heute morgen hat fast 5 Sekunden gedauert, jetzt sind es 3 Sekunden. Wahrscheinlich kam ich vorher auf 2 Sekunden weil alle Mitarbeiter schon im Feierabend waren..

 

[Powalowski]

Ein Bug oder Programmfehler ist eine nicht geplante Abweichung von der Anwendungslogik. Eine Verzögerung von 1-1.5 Sekunden ist eine tollerierbare Leistungsminderung. Und diese werden nicht mit höheren Prioritäten behandelt. Und manche von uns warten seit Jahren auf bestimmte Tickets.

Hallo,

der Wert schwankt teilweise bis zu 5 Sekunden und bei Aufträgen mit vielen Posten bricht die Bearbeitung teilweise ab. Das ist ein BUG🪲 Es sei denn, das ist die geplante Anwendungslogik, dann wäre aber was größeres im Argen.

Wenn es Probleme bei den Issues gibt, dann sollten wir mal die Leute suchen, die sich das blöde Produktionstool gewünscht haben. Das sind aus unserer Sicht verbrannte Resourcen, wenn die Basics nicht stimmen.

@mvh Wenn du meine Posts anschaust, teilen wir viele Lösungen die wir bauen mit der Community. Viele Feature Requests lassen sich auch mit Zusatztools und ein bisschen Anpassung bereits jetzt lösen. Bitte mach ein Ticket, damit dieser Bug mit der Auftragsbearbeitung endlich vom Tisch kommt. Falls es in eurer Firma gewünscht oder "tolerierbar" ist, dass die Auftragsbearbeitung hakt, dann kannst du ja lange auch in Zukunft auf der fehlerhaften 1.9.4.5 bleiben, die hat ja jetzt 2 Jahre Support.

 

[Powalowski]

Das sollte die 1.9.4.5 auch bringen, sie hat aber nur für sehr viel Frust bei unseren Mitarbeitern gesorgt.



Ich habe die beiden Pakete welche du Vorgeschlagen hast installiert. Leider hat es nicht geholfen. Der erste Auftrag heute morgen hat fast 5 Sekunden gedauert, jetzt sind es 3 Sekunden. Wahrscheinlich kam ich vorher auf 2 Sekunden weil alle Mitarbeiter schon im Feierabend waren..

Der Frust ist gigantisch, in einigen Bereichen ist bei uns die Arbeit komplett verlahmt. Insbesondere, wenn man schnell für die Kunden ein Problem im Auftrag lösen will.

 

[Powalowski]

Es gibt Rückmeldung von JTL:

Der Bug ist bekannt und wird wohl mit der 1.10 -möglicherweise- verbessert. Die Arbeit daran ist intern und wir können weder den Issue noch das Ticket sehen.

Es ist geplant die Leute durch den Bug nochmal zu einem Update der Major Version zu bringen. Bis dahin: Schneckenmodus und Geldverbrennung angesagt. 🐌🐌🐌

Leute macht Tickets auf, das so etwas überhaupt in Production landet ist eine Katastrophe.
@Enrico W. Wer könnte denn mal zuständig sein, dass hier Abhilfe geschaffen wird?

Auch ein Quickfix wäre denkbar aber für uns ist das ein fießer Knick in der Nutzbarkeit.

 

[littled]

Es gibt Rückmeldung von JTL:

Der Bug ist bekannt und wird wohl mit der 1.10 -möglicherweise- verbessert. Die Arbeit daran ist intern und wir können weder den Issue noch das Ticket sehen.

Es ist geplant die Leute durch den Bug nochmal zu einem Update der Major Version zu bringen. Bis dahin: Schneckenmodus und Geldverbrennung angesagt. 🐌🐌🐌

Leute macht Tickets auf, das so etwas überhaupt in Production landet ist eine Katastrophe.
@Enrico W. Wer könnte denn mal zuständig sein, dass hier Abhilfe geschaffen wird?

Auch ein Quickfix wäre denkbar aber für uns ist das ein fießer Knick in der Nutzbarkeit.

Der Fehler ist also bekannt aber uns wird im Ticket geraten einen externen SQL Experten anzuheuern?
Danke für die Information @Powalowski

 

[Powalowski]

Der Fehler ist also bekannt aber uns wird im Ticket geraten einen externen SQL Experten anzuheuern?
Danke für die Information @Powalowski

SQL Experten, das sind die wichtigsten Leute
Bitte öffnet Tickets Leute, das ist ja Wahnsinn. Mir ist aufgefallen, das Aufträge mit vielen Posten besonders langsam sind.

 

[Powalowski]

UPDATE: der Productowner ist informiert und JTL überlegt, wie es um diesen Fehler weiter geht. Hoffentlich ohne Major Update und hoffentlich zeitnah 👍🏻
Leute macht Tickets auf, vielleicht kommt das ja dann zeitnah vom Tisch.