Neu Langsame Pickgeschwindigkeit bei rollender Kommissionierung 1.6.

[jungwirbtgut]

Hallo,
wir haben auf der 1.6.45.2 das Problem, dass die Pickgeschwindigkeit beim Scannen bei der RoKo extrem langsam ist. Bei der 1.5. war das nicht.

Szenario:
Sobald man den Artikel gescannt hat und in die Box legt (nach Scannen der Box) bekommt man 1-4 Sekunden Ladezeit, je nachdem wie viel Artikel reserviert wurden.
Die Picklistengröße liegt bei 150+ Artikel, was nicht groß ist. Wir haben 16 Aufträge auf dem Wagen. Es ist egal ob 16 Aufträge und 16 Picks dann ist alles flott, es liegt nicht an der Auftragsmenge sondern an der Pickanzahl/Artikelmenge.

Erkenntnis:
Wir haben bereits rausgefunden, je KLEINER die reservierte Pickmenge auf der Pickliste, desto schneller die Ladezeit. Wenn z.B. nur 20 Artikel auf der Pickliste sind, ist es super flott. Über 300 braucht man garnicht anfangen zu picken.
Wir haben schon mit JTL Support gesprochen, mehrere JTL Agenturen dran gehabt bis dato hat keiner eine Lösung.
Jemand eine Idee?

DB ist ca. 20GB groß, ist ein Fulfiller mit mehreren Kunden. Die DB liegt auf einem seperaten Server.

Bin über jeden Tipp dankbar.

 

[forumjtlolshopag]

Ich würde dir raten direkt den Support anzuschreiben. Eventuell ist eine SQL Abfrage nicht optimal und müsste angepasst werden oder Alternativ fehlt irgendwo ein Index.
Weitere Möglichkeit wäre mal eine DB Optimierung laufen zu lassen. Die läuft bei uns z.B. 1mal am Tag spät Abends:
https://forum.jtl-software.de/threa...ich-automatisch-anstossen.194668/post-1039645

Wegen den 150 Artikeln und rollender Kommissionierung, ein Auftragslimit habt ihr da auch aktiv oder? Wir haben bei uns das Artikellimit auf 99999 und die Aufträge auf 16 eingeschränkt, weil nicht mehr Boxen auf dem Wagen sind.

 

[recent.digital]

Handelt es sich um einen SQL Standard oder SQL Express? Die 1.6 ist schon datenbankintensiver, der Tipp den Support zu kontaktieren könnte helfen.

 

[jungwirbtgut]

Ich würde dir raten direkt den Support anzuschreiben. Eventuell ist eine SQL Abfrage nicht optimal und müsste angepasst werden oder Alternativ fehlt irgendwo ein Index.
Weitere Möglichkeit wäre mal eine DB Optimierung laufen zu lassen. Die läuft bei uns z.B. 1mal am Tag spät Abends:
https://forum.jtl-software.de/threa...ich-automatisch-anstossen.194668/post-1039645

Wegen den 150 Artikeln und rollender Kommissionierung, ein Auftragslimit habt ihr da auch aktiv oder? Wir haben bei uns das Artikellimit auf 99999 und die Aufträge auf 16 eingeschränkt, weil nicht mehr Boxen auf dem Wagen sind.

Genau, habs grad mal editiert, war ne wichtige Info. Artikellimit ist aktuell auf 150 und Aufträge auf 16, aber oft pickt man halt weniger als 16. Bei uns passen auch nur 16 drauf. Der Support hat bis dato halt wirklich weitergeholfen, es wurde mal eine DB Spiegelung gemacht aber da tut sich nicht wirklich etwas.

Bzgl. der Optimierung der DB, haben wir schon 1000x gemacht, bringt garnichts ehrlich gesagt.. Statistiken wurden auch schon durch: "exec sp_updatestats" ausgeführt, aber ebenfalls keine Änderung.

W

 

[Svenka]

Hast du inzwischen etwas herausgefunden. Wir sind noch auf 1.5 und wollten eigentlich upgraden, aber das wäre ein Blocker.

 

[jungwirbtgut]

Hast du inzwischen etwas herausgefunden. Wir sind noch auf 1.5 und wollten eigentlich upgraden, aber das wäre ein Blocker.

Wenn du große Picklisten hast, tu es nicht! Außer du kannst es vorab erst einmal testen in einer Staging Umgebung.
Dass ist die JTL Antwort.

 

[Svenka]

Ernsthaft? 3 Sekunden pro Artikel ist innerhalb der Toleranz? Wie lange soll man beim picken denn benötigen? Habt ihr das nur bei der Roko, oder immer?

Ja wir haben große Picklisten, und ich bin wirklich froh das ich das hier vorher gelesen habe

 

[jungwirbtgut]

Ja, absoluter Witz. 150 Artikel auf der Pickliste á 3sek = 7,5min. Wartezeit, DANKE.

 

[recent.digital]

Ist das Verhalten JTL bekannt?

 

[recent.digital]

Wenn du große Picklisten hast, tu es nicht! Außer du kannst es vorab erst einmal testen in einer Staging Umgebung.
Dass ist die JTL Antwort.

Huch, wer lesen kann, ist klar im Vorteil.

Gibt es zumindest ein Issue-Tracker Link auf das man voten kann? Man kennt die Ursache nicht genau, es kann auch sein, dass es eine (un)erwünschte Wechselwirkung mit einer anderen Programmierung gibt.
Habt ihr den SQL Standard im Einsatz - ist die Datenbankleistung als Flaschenhalt auszuschließen?

 

[forumjtlolshopag]

Ja, hier sollte dringend nochmal nachgehakt werden, die Rückmeldung vom Support als auch von der Entwicklung ist unterirdisch. Wer entscheidet, das 3 Sekunden in der Toleranz ist? Eigtl. müssten wir von Millisekunden reden! Setzt man sich selbnst keine Qualitätsstandards? Alles andere ist Kontraproduktiv und zeigt, das da falsch entwickelt wurde. Vorallem, wenn es mit 1.5 flott genug vorher war. Öffentliches Ticket dazu wäre notwendig, damit genug darauf reagieren können. Wir würden sonst die 1.6 auch zurückstellen, bis das gelöst ist. RollKomm haben wir sehr häufig und ist laut unseren internen Zeitauswertungen so schon unter 1.5 an sich Zeitaufwendiger wie Eazy. Bei 1.6 mit dieser Latenz wäre das ein Ärgernis hoch 3.

 

[recent.digital]

(...) Öffentliches Ticket dazu wäre notwendig, damit genug darauf reagieren können.(..)

Ja, es braucht Feedback von möglichst vielen Usern. Eventuell kann @D.Hartl etwas Licht ins Dunkel bringen.