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

[intrinsicforce]

Mir ist aufgefallen, das Aufträge mit vielen Posten besonders langsam sind.

Bei mir sind's eigentlich immer 5-7 Sekunden, auch bei Aufträgen mit nur einer Artikelposition. Keine Anhänge oder sonst mit etwas überladen. Weiß aber auch nicht ob man Performance bei SQL Express '22 auf einem Shared Server mittlerer Preisklasse überhaupt erwarten darf...

 

[Powalowski]

Bei mir sind's eigentlich immer 5-7 Sekunden, auch bei Aufträgen mit nur einer Artikelposition. Keine Anhänge oder sonst mit etwas überladen. Weiß aber auch nicht ob man Performance bei SQL Express '22 auf einem Shared Server mittlerer Preisklasse überhaupt erwarten darf...

@intrinsicforce
JA! Das darf man nicht nur, sondern das muss man erwarten. Wir wollen einfache Aufträge bearbeiten und keine Gigabytes an kumulierten Big-Data Queries der letzten 15 Jahre..

So langsam geht es mir unter die Haut, dass sich hier keiner reihenweise beschwert. Als ob bei der Auftragsbearbeitung wunder was für Daten angefordert werden. Das können wir besser. Besonders bemerkenswert finde ich, dass das seit Monaten so sein muss und sich in dem Beitrag noch kein Mitarbeiter von JTL zu Wort gemeldet hat.

Ein offenen Issue finde ich zu dem Thema auch nicht. Es gibt Issues für jedes Thema aber Performance, die alle betrifft: "Hol dir einen SQL Berater"

Habt ihr alle Geld zum Verbrennen?

So eine Basisfunktion muss einfach schnell gehen.

-Das ist ein BUG🪲🪲- mach bitte ein Ticket auf, das kann ja wohl nicht sein.

Wie könnt ihr denn nur 5-7 Sekunden akzeptieren, ohne Ticket. Bitte meldet diesen Bug, omg. Ich fühle richtig mit.

 

[littled]

@intrinsicforce
JA! Das darf man nicht nur, sondern das muss man erwarten. Wir wollen einfache Aufträge bearbeiten und keine Gigabytes an kumulierten Big-Data Queries der letzten 15 Jahre..

So langsam geht es mir unter die Haut, dass sich hier keiner reihenweise beschwert. Als ob bei der Auftragsbearbeitung wunder was für Daten angefordert werden. Das können wir besser. Besonders bemerkenswert finde ich, dass das seit Monaten so sein muss und sich in dem Beitrag noch kein Mitarbeiter von JTL zu Wort gemeldet hat.

Ein offenen Issue finde ich zu dem Thema auch nicht. Es gibt Issues für jedes Thema aber Performance, die alle betrifft: "Hol dir einen SQL Berater"

Habt ihr alle Geld zum Verbrennen?

So eine Basisfunktion muss einfach schnell gehen.

-Das ist ein BUG🪲🪲- mach bitte ein Ticket auf, das kann ja wohl nicht sein.

Wie könnt ihr denn nur 5-7 Sekunden akzeptieren, ohne Ticket. Bitte meldet diesen Bug, omg. Ich fühle richtig mit.

Ich beschäftige mich jetzt seit einem halben Jahr mit JTL, und die gleiche Frage, warum sich so wenig Leute beschweren, habe ich mir auch schon gestellt. Es wunder mich, wenn ich mir aber die IT in Deutschland anschaue wundert es auch wieder nicht
Zu den Tickets, bringt es denn überhaupt was? Wieso sind Tickets von 2017/2018, wenn ich nach den meisten votes sortiere, immer noch nicht implementiert?

 

[Powalowski]

Ich beschäftige mich jetzt seit einem halben Jahr mit JTL, und die gleiche Frage, warum sich so wenig Leute beschweren, habe ich mir auch schon gestellt. Es wunder mich, wenn ich mir aber die IT in Deutschland anschaue wundert es auch wieder nicht
Zu den Tickets, bringt es denn überhaupt was? Wieso sind Tickets von 2017/2018, wenn ich nach den meisten votes sortiere, immer noch nicht implementiert?

Unbedingt ein Ticket eröffnen - Issues sind oftmals Feature Requests aber das hier ist ein BUG 🪲 Und diese müssen jawohl behoben werden.

 

[intrinsicforce]

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.

Würde sagen da kommt man der Ursache schon näher. Denn Angebote laden bei mir genauso lange wie Aufträge (außer beim ersten Öffnen nach Wawi-Start, da warte ich auch schon mal 15 sekunden).

Rechnungen, die sich ja nur einmal je Wawi-Instanz öffnen lassen, kommen hingegen sehr viel schneller.

 

[Powalowski]

EDIT (bestätigt, weiter getestet)

⚠️⚠️⚠️Es ist gleichzeitig ein Memoryleak

Siehe:
https://forum.jtl-software.de/threa...emoryleak-beim-oeffnen-von-auftraegen.222193/

Macht mal (neue Exe, alte auch ) 10x einen Auftrag auf und zu, kann der gleiche sein. Schaut zu wie der Speicherverbrauch wächst 🪲

 

[intrinsicforce]

Bestätige...

Das ist definitiv ein Bug! Was für Daten werden da wohl in den Speicher geladen, und warum? Macht ja kein Sinn diese nach dem Schließen des Auftrags weiter zwischenzulagern. Bei erneutem Öffnen des Auftrags werden die Daten sicherlich nicht aus dem RAM gezogen, sonst wäre der Auftrag schneller da - und enthält möglicherweise auch noch veraltete Daten, wenn dieser zwischenzeitlich durch andere Instanz bearbeitet wurde.

 

[Powalowski]

Bestätige...

Das ist definitiv ein Bug! Was für Daten werden da wohl in den Speicher geladen, und warum? Macht ja kein Sinn diese nach dem Schließen des Auftrags weiter zwischenzulagern. Bei erneutem Öffnen des Auftrags werden die Daten sicherlich nicht aus dem RAM gezogen, sonst wäre der Auftrag schneller da - und enthält möglicherweise auch noch veraltete Daten, wenn dieser zwischenzeitlich durch andere Instanz bearbeitet wurde.

Ticket, Ticket, Ticket... 👍🏻👌🏻

 

[intrinsicforce]

Ticket, Ticket, Ticket... 👍🏻👌🏻

Ist raus.. Gut beobachtet!

 

[ple]

Da du ja gerade ein wenig Feuer hier machst
https://forum.jtl-software.de/threa...ich-ab-zu-wenig-arbeitsspeicher.203734/page-4

Glaube das ist schon seit der 1.6 so, das der ram vollläuft. Irgendwer hatte das auch mal mit Aufträge öffnen schließen getestet.
Frag mich aber nicht, warum jtl dahingehend bisher nichts unternommen hat außer die Sharp Version zu nutzen.

leider ist das alles ein wenig gefrickel mit jtl. Denke da fehlt Manpower und Priorisierung, hoffe das bessert sich bald.

 

[Powalowski]

Da du ja gerade ein wenig Feuer hier machst
https://forum.jtl-software.de/threa...ich-ab-zu-wenig-arbeitsspeicher.203734/page-4

Glaube das ist schon seit der 1.6 so, das der ram vollläuft. Irgendwer hatte das auch mal mit Aufträge öffnen schließen getestet.
Frag mich aber nicht, warum jtl dahingehend bisher nichts unternommen hat außer die Sharp Version zu nutzen.

leider ist das alles ein wenig gefrickel mit jtl. Denke da fehlt Manpower und Priorisierung, hoffe das bessert sich bald.

Danke für die Info, am besten gleich mal ein Ticket eröffnen👍🏻Für uns ist es schwer bei der Situation mit Aufträgen zu arbeiten und an sich halte ich es für sehr wichtig, dass die Anwender diesen Bug nicht einfach passieren lassen. Das ist ja das beste Feedback, das JTL bekommen kann, wenn das schon durch die Tests gerutscht ist irgendwie.

Gut zu wissen, dass @Enrico W. den Beitrag hier sehen sollte, ich bin ehrlich gesagt ein wenig überrascht, dass solche Änderungen zwar rausgedrückt werden an die Kunden aber JTL sich nicht mindestens Mal mit einem Issue oder Ähnlichem dazu äußert.

 

[mvh]

Danke für die Info, am besten gleich mal ein Ticket eröffnen👍🏻Für uns ist es schwer bei der Situation mit Aufträgen zu arbeiten und an sich halte ich es für sehr wichtig, dass die Anwender diesen Bug nicht einfach passieren lassen. Das ist ja das beste Feedback, das JTL bekommen kann, wenn das schon durch die Tests gerutscht ist irgendwie.

Gut zu wissen, dass @Enrico W. den Beitrag hier sehen sollte, ich bin ehrlich gesagt ein wenig überrascht, dass solche Änderungen zwar rausgedrückt werden an die Kunden aber JTL sich nicht mindestens Mal mit einem Issue oder Ähnlichem dazu äußert.

https://issues.jtl-software.de/issues/WAWI-76186 Wird in 1.10 gelöst.

 

[Powalowski]

Wunderbar 👍🏻 Ich hoffe doch, dass das auch die Geschwindigkeit optimiert und nicht nur den Arbeitsspeicher ☝🏻😉

 

[Powalowski]

Funfact:
Das Rendern des Auftrags mit List&Label als PDF geht ca. Faktor 7 schneller als die Bearbeitungsmaske zu öffnen.
Für die SQL-Optimierer unter uns: Sind das denn nicht die gleichen Daten?

 

[forumjtlolshopag]

Frag mich aber nicht, warum jtl dahingehend bisher nichts unternommen hat außer die Sharp Version zu nutzen.

Das wäre eine Frage an den Product Owner. Wahrscheinlich war ihm das Problem nicht bewusst, weil sich zu wenig gemeldet haben. Es zeigt mir auf jeden Fall dass das interne Testing entweder garnicht durchgeführt wird oder sehr unzureichend. Gerade für solche Fälle sollte doch intern mit massiven Datenbanken getestet und Zeiten für gängige Arbeitsschritte erfasst werden. Wenn man sich da als Softwarehersteller dann auch Zeitschwellen setzt, wäre das viel eher aufgefallen, das da etwas zu langsam für den Endverbraucher ist. JTL zielt doch eigtl. nicht nur auf kleine Unternehmen sondern auch auch Großkunden ab.

 

[Powalowski]

Es gibt jetzt einen Issue mit der Bitte um Voting.

🎫TICKET: https://issues.jtl-software.de/issues/WAWI-77156


Ich verstehe nicht, warum wir für die Lösung einer Selbstverständlichkeit, die niemals so hätte ausgerollt werden sollen jetzt voten müssen.

 

[AlexMT-Commerce]

Bei uns dauerts auch bei jedem Auftrag zwischen 3 bis 10 Sekunden. Grundsätzlich habe ich das immer auf das cloudhosting geschoben. Wir hosten über ecomdata. Aber dann hoffen wir doch mal, dass sich mit der 1.10 etwas verbessert.

 

[SebiW]

Es gibt jetzt einen Issue mit der Bitte um Voting.

🎫TICKET: https://issues.jtl-software.de/issues/WAWI-77156


Ich verstehe nicht, warum wir für die Lösung einer Selbstverständlichkeit, die niemals so hätte ausgerollt werden sollen jetzt voten müssen.

Weil JTL priorisieren muss. Es sind keineswegs alle Installationen von diesem Problem betroffen. Sonst wäre der Aufschrei um ein vielfaches größer.
Und es gibt andere Fehler die potentiell kritischer sind. Dieser Fehler ist für Euch halt besonders schwerwiegend, andere Fehler oder Features sind für andere Kunden wichtiger.

 

[Powalowski]

Weil JTL priorisieren muss. Es sind keineswegs alle Installationen von diesem Problem betroffen. Sonst wäre der Aufschrei um ein vielfaches größer.
Und es gibt andere Fehler die potentiell kritischer sind. Dieser Fehler ist für Euch halt besonders schwerwiegend, andere Fehler oder Features sind für andere Kunden wichtiger.

Wie schnell öffnet sich denn bei dir ein Auftrag? Ich gehe davon aus, dass ihr dann so eine Zauberinstanz habt, bei der es schnell geht?

Der Memory-leak wird ja wohl kaum instanzabhängig sein. Ich habe noch keinen einzigen Nutzer gefunden, bei dem es unter 1 Sekunde geht. Des weiteren war ich bei einer befreundeten Firma, die ebenfalls JTL einsetzt und zu unserem Entsetzen ging es dort stabil 5+ Sekunden und die haben schon gar keine Tickets mehr erstellt, weil es ebenso wie bei uns nur einer von vielen Fehlern ist, der zu Problemen führt.

Auftragseditor öffnen über 2 Sekunden ist ein eindeutiger Bug, der schwerwiegend genug ist, sodass es -vor der Veröffentlichung- hätte behoben sein müssen.

NACHTRAG: ich denke der Thread ist der meistgeöffnete Beitrag im JTL 1.9 Forum.

 

[SebiW]

Die einfache Antwort ist: Schnell genug. Wir brauchen den Prozess relativ selten, haben keine telefonische Auftragsannahme etc. Unsere Aufträge kommen rein, werden automatisiert abgefertigt und nur die relativ seltenen Problemfälle müssen händisch bearbeitet werden.
Dass die Öffnungszeit für Euch ein Problem ist liegt an Euren Prozessen. Und damit meine ich nicht dass Eure Prozesse schlecht sind sondern nur, dass eben keineswegs jeder so arbeitet wie ihr. Für uns stellt die Ladezeit von 1-2 Sekunden schlicht kein Problem dar. Für viele andere auch nicht.
Geht schon damit los dass die meisnte JTL User noch nichtmal auf 1.9 sind.