In Bearbeitung Datenabgleich mit WAWI Performance

[MLiebschner]

Hallo Forengemeinde,

vielleicht weiß einer von Euch Rat.

Wir haben JTL-POS 0.9.7.4 in Verbindung mit JTL-Wawi 1.5.14.3 testweise installiert. Nun versucht POS die Daten der WaWi anzugleichen.

Das endet nach einigen Minuten mit folgendem Bild:

Auf dem POS-Server erscheint eine Exception:

(Server) [12.02.2020 11:02:24] System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.Runtime.Remoting.RemotingException: Das Objekt "/c6e6c9e6_7656_4b41_870d_c9332393297b/+qyq14sxp7_5oyy7munflnnr_8.rem" wurde getrennt oder ist nicht auf dem Server vorhanden.
bei JTL.Wawi.PosServer.ConsoleWriter.WriteLine(String value)
bei System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
bei System.Console.WriteLine(String value)
bei JTL.Wawi.Sync.Core.Logging.PosLogger.Enqueue(LogeintragSchweregrad severity, String message, ILogEntryData data)
bei jtlTools.Logging.LoggerExtensions.Debug(ILogger logger, String message)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetSteuersatz(Int32 companyId, Int32 steuerklasseId)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.ErmittleBruttoPreis(IList`1 result)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetProducts(Int32 limit, Int64 lastChanged)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetAllProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.GetArtikel(IPosCommand`1 posCommand)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.HandleProducts(IPosCommand`1 command)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.<>c__DisplayClass19_0.<ExecuteAsync>b__0()
bei System.Threading.Tasks.Task`1.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
bei System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
bei System.Threading.Tasks.Task`1.get_Result()
bei JTL.Wawi.PosServer.Controller.ProductController.GetProducts()
bei System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
bei System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
bei JTL.Wawi.PosServer.AppDomains.AppDomainExtension.DoCallBackWithData[T](AppDomain appDomain, CrossAppDomainDelegate appDomainDelegate, Object data)
bei JTL.Wawi.PosServer.Controller.AppDomainApiControllerBase.<ExecuteInAppDomainAsync>d__5`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei JTL.Wawi.PosServer.Controller.ProductController.<Get>d__0.MoveNext()
---> (Interne Ausnahme #0) System.Runtime.Remoting.RemotingException: Das Objekt "/c6e6c9e6_7656_4b41_870d_c9332393297b/+qyq14sxp7_5oyy7munflnnr_8.rem" wurde getrennt oder ist nicht auf dem Server vorhanden.
bei JTL.Wawi.PosServer.ConsoleWriter.WriteLine(String value)
bei System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
bei System.Console.WriteLine(String value)
bei JTL.Wawi.Sync.Core.Logging.PosLogger.Enqueue(LogeintragSchweregrad severity, String message, ILogEntryData data)
bei jtlTools.Logging.LoggerExtensions.Debug(ILogger logger, String message)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetSteuersatz(Int32 companyId, Int32 steuerklasseId)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.ErmittleBruttoPreis(IList`1 result)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetProducts(Int32 limit, Int64 lastChanged)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetAllProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.GetArtikel(IPosCommand`1 posCommand)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.HandleProducts(IPosCommand`1 command)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.<>c__DisplayClass19_0.<ExecuteAsync>b__0()
bei System.Threading.Tasks.Task`1.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()<---

(Server) [12.02.2020 11:02:24] System.Runtime.Remoting.RemotingException: Das Objekt "/c6e6c9e6_7656_4b41_870d_c9332393297b/+qyq14sxp7_5oyy7munflnnr_8.rem" wurde getrennt oder ist nicht auf dem Server vorhanden.
bei JTL.Wawi.PosServer.ConsoleWriter.WriteLine(String value)
bei System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
bei System.Console.WriteLine(String value)
bei JTL.Wawi.Sync.Core.Logging.PosLogger.Enqueue(LogeintragSchweregrad severity, String message, ILogEntryData data)
bei jtlTools.Logging.LoggerExtensions.Debug(ILogger logger, String message)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetSteuersatz(Int32 companyId, Int32 steuerklasseId)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.ErmittleBruttoPreis(IList`1 result)
bei JTL.Wawi.Sync.Core.Domain.Pos.Calls.Artikel.PosProductRepository.GetProducts(Int32 limit, Int64 lastChanged)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetAllProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Domain.Pos.FrontendDbAdapter.PosProductDbAdapter.GetProducts[TCommandType](IPosCommand`1 commandType)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.GetArtikel(IPosCommand`1 posCommand)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.HandleProducts(IPosCommand`1 command)
bei JTL.Wawi.Sync.Core.Services.Pos.PosFrontend`2.<>c__DisplayClass19_0.<ExecuteAsync>b__0()
bei System.Threading.Tasks.Task`1.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()

Der Abgleich wird im selben Netzwerk durchgeführt.

Grundsätzlich stellt sich mir auch die Frage wie lange der Abgleich von ca. 63000 Artikeln dauert?

Gruß
Maik

 

[Janusch]

Hallo,
danke für die Rückmeldung. Das Problem sollte mit der Wawi 1.5.14.4 nicht mehr auftreten. Diese wird aktuell vorbereitet für Release.

Die Artikelübertragung hängt davon ab ob Bilder vorhanden sind und wie groß diese sind. Mit unseren Daten schaffen wir ca. 400 Artikel pro Minute im lokalen Netzwerk.

 

[MLiebschner]

Hallo,

mittlerweile testen wir auf JTL-Wawi 1.5.15.1 und JTL-Pos 1.0.0.0 auf Android 8.1.0. Der Abgleich bricht nun nicht mehr mit oben genannter Meldung ab.

Allerdings macht uns die Performance immernoch Probleme. Gestoppt braucht die Kasse 7 Minuten 19 Sekunden fuer 20 Artikel. Das wuerde fuer alle Artikel ca. 16 Tage dauern.
Alle Artikel haben Bilder welche ca. 50-150 kb gross sind und eine Breite von ca 1920 Pixeln aufweisen.

Der SQL Server laeuft als Testsystem auf 2x2 3.5 Ghz Xeon Prozessoren, 32 GB Ram und SSD`s
Das Android laeuft auf 1x2 2.8 GHz Xeon Prozessoren, 4 GB Ram und SAS HDD`s

Beide sind nicht gerade ausgelastet...Bedienung der Kasse läuft super.
Alles nicht High End, aber vielleicht habt Ihr noch einen Tipp an welcher Stellschraube man drehen kann.

Ich befürchte das es mit einem dediziertem Tablet auch nicht besonders schneller laufen wird.

Gruß
Maik

 

[Janusch]

Hallo,
es ist so schwer zu sagen was da die Bremse ist. Das sind ca. 22 Sek. pro Artikel, Emulation könnte eine der wahrscheinlichen Ursachen sein. Bei dem Server müssten mind. 5 Artikel pro Sek. gehen.

 

[MLiebschner]

Hallo Janusch,

wir haben nun doch einmal dediziertes Android verwendet und dem SQL Server ein wenig mehr Ressourcen gegeben. Nun werden in 7-8 Minuten 20 Artikel abgeglichen. Der SQL Server lastet 2 CPU vollständig aus:



Kann es ein Problem mit der Datenbank sein?

Gruß
Maik

 

[McAvity]

@MLiebschner

Welche Version des SQL Server ist es denn? Vielleicht die Express-Version? Weil die nutzt maximal 1,4GB RAM.

Ansonsten kannst Du die Performance des SQL-Servers mal mit den Hinweisen aus diesem Posting prüfen: https://forum.jtl-software.de/threads/jtl-ziemlich-langsam.127277/#post-695626

MfG

McAvity

 

[MLiebschner]

Hallo McAvity,

ist eine Standard Version 2016. Im produktiven Bertrieb verbraucht die bis zu 22 GB Arbeitsspeicher. Das Testsystem ist gerade 3 Tage an und es arbeitet keiner drauf. Nur die eine Kasse läuft als Testanbindung und synchronisiert die ganze Zeit.

 

[McAvity]

@MLiebschner

In wieweit unterscheidet sich das Testsystem von der Hardware denn vom Produktivsystem?
Hardwaredefekt kann ausgeschlossen werden (besonders RAM)?

MfG

McAvity

 

[MLiebschner]

Das Testsystem hat 2 Prozessorkerne mehr und statt 64GB nur 32Gb Ram. Sonst ist es gleich. Die Wawi selber läuft schnell wie auch auf dem Produktivsystem.

Folgende Abfrage scheint sehr ressourcenintensiv zu sein?

 

[McAvity]

@MLiebschner

Da muss ich passen, da sollte vielleicht lieber mal @Janusch seine Meinung zu abgeben.

Ist das denn eine Kopie eurer Produktivdatenbank?

MfG

McAvity

 

[MLiebschner]

@McAvity

Ja, eine Kopie.
Unsere Produktivdatenbank läuft noch auf WAWI 1.5.10.0. Zum Testen haben wir die geclont und auf 1.5.15.1 aktualisiert.

 

[McAvity]

@MLiebschner

Wenn der natürlich jedes Mal und immer wieder die 63000 Artikel auf Veränderungen prüft kann ich mir schon vorstellen dass das langsam ist.
Habt Ihr mal versuchsweise die Anzahl der Artikel (z.B. durch Löschen von 90% der Artikel) zu verringern?
Dann hätte man vielleicht eine Tendenz ob es daran liegt.

Ansonsten müssten da mal die Spezialisten von JTL dran.

MfG

McAvity

 

[Janusch]

Hallo,
die Kollegen haben hier das Problem gefunden, es wird im nä. Wawi - Update ein Fix für geben.

 

[Philipp K.]

Hallo @MLiebschner,

wir haben in den letzten Versionen (akt. 1.0.1.1) einiges am Abgleich verändert, bei internen Tests haben wir Datenbanken 5-6x schneller übertragen.

Wie verhält sich die aktuelle Version bei eurer Datenbank, läuft der Abgleich effizienter?

Viele Grüße

Philipp

 

[MLiebschner]

Hallo Philipp,

getesten nun mit JTL Wawi 1.5.20.0 und JTL-Pos 1.0.1.1 (2679).

Abgleich geht auf jeden Fall schneller, anbei ein kleines Video.

Ca. 2 Minuten für 381 Artikel, das macht für alle 56640 Artikel ca 5 Stunden. Das allerdings im W-Lan, wie lange das in den einzelnen Filialen über VPN dauert, konnte ich bisher nicht testen.

Leider läuft der Abgleich nicht bis zum Ende, da der Interne Speicher des EDA51 (5GB) durch die große Anzahl der Bilder ruck zuck voll ist. database or disk is full (code 13)
Kann man Bilder nur als " Cache" übertragen lassen wenn ein Artikel oder Artikelliste das erste mal aufgerufen wird? Müssen grundsätzlich alle Bilder übertragen werden?



Oder vielleicht wäre eine Option für online/offline arbeiten sinnvoll, dass man nach Anbindung an den Server online immer arbeiten kann und die Kasse meinetwegen im Hintergrund eine "Offline-Kopie" erstellt.

 

[Philipp K.]

Hallo Philipp, getesten nun mit JTL Wawi 1.5.20.0 und JTL-Pos 1.0.1.1 (2679). Abgleich geht auf jeden Fall schneller, anbei ein kleines Video. Ca. 2 Minuten für 381 Artikel, das macht für alle 56640 Artikel ca 5 Stunden. Das allerdings im W-Lan, wie lange das in den einzelnen Filialen über VPN dauert, konnte ich bisher nicht testen. Leider läuft der Abgleich nicht bis zum Ende, da der Interne Speicher des EDA51 (5GB) durch die große Anzahl der Bilder ruck zuck voll ist. database or disk is full (code 13). Kann man Bilder nur als "Cache" übertragen lassen wenn ein Artikel oder Artikelliste das erste mal aufgerufen wird? Müssen grundsätzlich alle Bilder übertragen werden? Oder vielleicht wäre eine Option für online/offline arbeiten sinnvoll, dass man nach Anbindung an den Server online immer arbeiten kann und die Kasse meinetwegen im Hintergrund eine "Offline-Kopie" erstellt.

Hallo @MLiebschner

freut mich zu hören, dass sich die Performance spürbar verbessert hat.

Wir haben den Abgleich so umgebaut, dass zuerst alle Stammdaten übertragen werden und erst im Anschluss die Bilddateien. Das hat zur Folge, dass Du bereits nach dem Abgleich der Stammdaten arbeiten kannst, da die Bilder in der Regel vernachlässigbar sind. Zudem arbeiten wir aktuell an einer Möglichkeit die gesamten Grafiken ausgelagert auf einer SD-Karte zu speichern, während die Stammdaten im internen Speicher des Gerätes bleiben. Das kann zwar zu Einbusen in der Performance von JTL-POS führen, aber da müssen wir aufgrund der vielen Faktoren einfach abwarten.

Was meinst Du mit "als Cache übertragen"? Die Wawi rechnet die Bilddateien vor der Übertragung an JTL-POS bereits auf etwa 500px x 500px runter. Die Frage die ich mir aber gerade Stelle: Wie groß sind Deine Artikelbilder durchschnittlich? Eventuell können wir da noch etwas optimieren, größer als 50kb sollten die Bilder keinesfalls sein. Dann wären das theoretisch ca. 3,5GB bei 63.000 Artikeln, weshalb die Bilddateien nach dem Abgleich sogar unter 3,5GB liegen müssten. Stammdaten sind in der Größe vernachlässigbar, daher bleibt jetzt noch die Frage nach der Größe des Betriebsystems?

Viele Grüße

Philipp

 

[McAvity]

@Philipp K.

Wnn ich @MLiebschner richtig verstehe meint er mit "als Cache übertragen" dass die Bilder nur vom Server angefordert werden, wenn man das Bild wirklich betrachten möchte.
Also z.B. so, dass auf dem Tablet zunächst nur die Artikeldaten oder Bilder gespeichert werden und das nur im Bedarfsfall und bei bestehender Verbindung zu Server die Bilddaten das Artikels geladen werden.

Wäre es denn nicht eine Option, initial (bei großer Artikelanzahl) sämtliche Bilder auf dem Server in der optimierten Version zu erstellen, diese in ein Archiv (oder mehrere kleine Archive z.B. als ZIP) zu packen und die dann auf das Tablet zu laden und dort wieder zu entpacken? Oder die Möglichkeit zu schaffen, diese Bildarchive manuell auf eine SD-Karte zu kopieren und von dort auf dem Tablet in die POS zu laden?

MfG

McAvity

 

[MLiebschner]

@Philipp K.

Etwas Laienhaft gesprochen, da ich nicht weiß was man auf Android so programmieren kann:

Der Kassenserver sollte seine Bilder immer auf das Optimum (was die Kasse benötigt) komprimieren. Das kann ja auf dem Server im Hintergrund und nach bestimmten Regeln erfolgen und somit sein eigenes Repository aufbauen.

Wenn jetzt in der Kasse auf dem Tablet ein Artikel oder eine Artikelübersicht geöffnet wird, sollte das Programm vorerst im eigenen Speicher ( Cache) nachschauen, ob das Bild da schon vorhanden ist. Wenn nicht, solle die Kasse versuchen es online vom Kassenserver anzeigen zu lassen, falls es da schon optimiert wurde. Gleichzeitig sollte die Kasse es dann im Hintergrund in den eigenen Chache auf dem Tablet laden.

Falls es auf dem Kassenserver noch nicht optimiert wurde, einfach kein Bild anzeigen.

Jetzt könnte man auf dem Tablet noch speichern, wann das letzte Mal das Bild eines Artikels in der Kassenoberfläche angezeigt wurde. Wenn das nun schon XYZ Monate her war, würde ich das aus dem Cache des Tablets automatisch (oder auch manuell in den Optionen) löschen lassen. Dann würde sich das System wieder automatisch bereinigen.

Änderungen an Bilder müssten natürlich auch irgendwie geprüft werden, nicht das die Kasse falsche alte Bilder anzeigt.

Unsere Bilder im JTL sind immer 1920 breit und haben eine Größe von 100-250 kb.

Gruß Maik