Wawi 107 Performance (Ameise)

[maydo]

Hi,

vorneweg super Arbeit an das JTL Team, die allgemeine Performance in 107 zieht ein WOW Effekt mit sich.
Unterschied wie Tag und Nacht zu <106.

Jedoch ist die Performance der Ameise immer noch massiv im Keller.
Eine Vorlage mit ca. 20k Artikeln war vorher (in irgendeiner 1er Version schneller als jetzt, wobei die gleiche Vorlage in 923 am schnellsten war)
In 106 und auch in 107 (kein Unterschied) benötigt die Ameise locker 3 Stunden.
Vorherige Versionen knapp 45Min.

Hier sollte noch kräftig nachgebessert werden.
Man kann richtig zuschauen wie der fortlaufende Zähler 1,2,3....usw im Sekundentakt oder sogar langsamer rattert.

 

[Björn Berger]

AW: Wawi 107 Performance (Ameise)

Hi maydo

Erstmal Danke für das Lob.
Die Ameise sollte eigentlich auch merklich schneller geworden sein.
Kannst du mir ein paar mehr Informationen geben.
Ich vermute mal Artikelimport, mit was für Spalten denn?

Gruß
Björn

Gruß
Björn

 

[maydo]

AW: Wawi 107 Performance (Ameise)

hi Björn,

du hast die csv (ca. 19-20k artikeln) datei eigentlich schon mit datenbank hatte ich dir mal zur verfügung gestellt, der import war mal deutlich schneller, in welcher version weiss ich nicht mehr.
jedoch derzeit echt extrem lahm

 

[Björn Berger]

AW: Wawi 107 Performance (Ameise)

Hi

Daten die wir von Kunden zur Verfügung gestellt bekommen werden nach erfolgreicher Lösung bei uns gelöscht.
Was du schonmal versuchen kannst ist in der Jtl Datenbankverwaltung die Performanceoptimierung laufen zu lassen, damit die Indizes neu organisiert werden.
Wenn das nix bringt bräuchte ich am besten nochmal deine DB und Csv, schick mir dann ne pn.

Gruß
Björn

 

[maydo]

AW: Wawi 107 Performance (Ameise)

hi Björn,

Performanceoptimierung habe ich getestet, nicht unbedingt schneller geworden.
Ich schick dir gleich ne PN, mit DB und csv. Noch am uploaden.

gruss

 

[css-umsetzung]

AW: Wawi 107 Performance (Ameise)

Ich habe einen Kunden der ca. alle 2 Monate seine Artikel löscht und dann über die Ameise, diese wieder importiert.
Wir reden hier von 260 000 Artikel in der 923er und der 2005er Express DB ging das an einem Weekend, incl. dem Abgleich zum Shop, das Einspielen und der Abgleich erfolgte immer in Etappen ich glaube 20 000 oder 40 000 in einem Durchgang.

Nun braucht er für diesen Import die 4 bis 5fache Zeit bei einer 2012er Express DB.
Es ist jetzt gerade etwas schwer, dem Kunden zu erklären wie gut es war auf eine neuere Datenbank und die neue Wawi zu wechseln

Wir haben die Optimierungsmöglichkeiten die die Wawi bietet voll ausgeschöpft.
Und ja ich weiß das man bei der Menge eine Lizenzversion von SQL nehmen sollte, muss aber dem Kunden recht geben, wenn er sagt, vorher rannte alles und das seit Jahren.

 

[maydo]

AW: Wawi 107 Performance (Ameise)

Ich habe einen Kunden der ca. alle 2 Monate seine Artikel löscht und dann über die Ameise, diese wieder importiert.
Wir reden hier von 260 000 Artikel in der 923er und der 2005er Express DB ging das an einem Weekend, incl. dem Abgleich zum Shop, das Einspielen und der Abgleich erfolgte immer in Etappen ich glaube 20 000 oder 40 000 in einem Durchgang.

Nun braucht er für diesen Import die 4 bis 5fache Zeit bei einer 2012er Express DB.
Es ist jetzt gerade etwas schwer, dem Kunden zu erklären wie gut es war auf eine neuere Datenbank und die neue Wawi zu wechseln

Wir haben die Optimierungsmöglichkeiten die die Wawi bietet voll ausgeschöpft.
Und ja ich weiß das man bei der Menge eine Lizenzversion von SQL nehmen sollte, muss aber dem Kunden recht geben, wenn er sagt, vorher rannte alles und das seit Jahren.

Hi

JTL ist an dem Thema schon dran.
Wir haben auch Performance Ameisenprobleme.

 

[Björn Berger]

AW: Wawi 107 Performance (Ameise)

Hi

Mit der kommenden Version 1.0.10.0 ist nochmal ein Zeitfresser beim Artikelimport mit der Ameise eliminiert worden.
Damit sollte der Artikelimport wieder in der Nähe der Geschwindigkeit der 923 sein.

Evtl könnte man auch mal Nachhaken warum der komplette Artikelstamm gelöscht wird.
Aus Sql Server Sicht ist das nicht Optimal, da muss der Sql Optimierer jedesmal die Statistiken neu bauen und die Indices sollten neu Organisiert werden.

Gruß
Björn

 

[css-umsetzung]

AW: Wawi 107 Performance (Ameise)

Danke für die Info,

Das liegt daran, dass diese Menge an Artikel nicht mehr handelbar ist und sich im Elektronik Geschäft die Artikel die raus fliegen und neu reinkommen, ständig ändern.
Da können an einem Tag also gut und gerne mal 300 Artikel wegfallen, der Kunde bekommt diese Info aber nur Monatlich oder alle zwei Monate, Niemand sagt welche Artikel raus geflogen sind, es gibt einfach nur eine neue Liste mit (+/-) 260 000 Artikeln.

Ich verstehe das diese Vorgehensweise nicht förderlich ist, sich aber bei der Menge der Artikel nicht optimieren lässt.

 

[utuz]

AW: Wawi 107 Performance (Ameise)

Man kann das was ich jetzt schreibe nicht direkt vergleichen, aber eventuell könnte das als Denkansatz dienen.
In meinem alten Shop, auch wenn wir gerade von der WAWI reden, gab und gibt es keinen automatismuss, veränderte Daten aus der Datenbank zu entfernen.
Ich habe mir da über die Jahre so geholfen, dass ich Artikeldaten die über eine Tabelle eingelesen werden zweimal eingelesen habe.
Zweimal warum?
Um eine Möglichkeit zu finden wie man Artikel aus zwei Tabellen miteinander vergleichen kann, habe ich in die Tabelle eine Spalte "Lieferzeit-1" mit Inhalt "0" eingefügt.

Beim aller erstenmal wird die Tabelle mit der regulären Lieferzeit eingelesen.
Nun kommt eine neue Tabelle mit neuen Daten, die nur in Teilen noch identisch ist mit den Daten der vorherigen Tabelle. In diese Neue Tabelle füge ich nun die Spalte Lieferzeit-1 mit Inhalt "0" hinzu.
Dann lese ich diese Tabelle ein und ordne bei der Lieferzeit nun diese Spalte Lieferzeit-1 zu.
Der Effekt ist der, dass nun bei allen neuen und alten Artikel die in der neuen Tabelle noch vorhanden sind die Lieferzeit auf "0" steht.
In der Datenbank befinden sich nun Artikel mit Lieferzeit aus der vorherigen Tabelle und eben Artikel deren Lieferzeit mit dem Wert "0" angegeben ist.

Nun filtere ich diese Artikel mit einer Lieferzeit heraus und kann diese löschen und habe somit nur noch Artikel mit dem Wert "0" der neuen tabelle in der Datenbank.
Im Anschluss lese ich diese Neue Tabelle nun mit dem regulären Lieferzeitentexten, oder sonstigen Angaben noch mal ein und schon ist das entsprechend aktuaslisiert.
Bei 260000 Artikel stellt das natürlich in erster Linie einen Zeitaufwand dar, aber nicht jeder hat diese Datenmengen zu verwalten.
Wie gesagt, es geht um einen Denkansatz.
Wie man das mit einer SQL Datenbank umsetzen könnte weiß ich allerdings nicht.
Gruß Joachim

Kleiner Nachtrag noch.
Da man Artikel, die bereits in Verwendung für Angebote Rechnungen etc. sind, nicht einfach löschen kein, weil die ja noch benötigt werden können, sollten bei der Löschung der überzähligen Artikel entsprechend automatisch ausgefiltert und in ein Archiv geschoben werden.

 

[Marc Völker]

AW: Wawi 107 Performance (Ameise)

Hallo,

also zu deinem Problemcss-umsetzung bzw die deines Kunden ist das Defintiv Sub Optimal, solange es nur Artikel Betrifft die keine History (Käufe, Warenbewegungen etc) aber okay. Wenn auch für die DB dennoch suboptimal. Grundsätzlich Artikel die nicht mehr kaufbar sind festzustellen ist aber kein Problem.

Entweder es wird dann auf eine Programmatische Lösung gesetzt, welche das erkennt. Und die Dann löscht / Inaktiv setzt falls history vorhanden. Oder wenn es über die Ameise sein muss, einmal per DB alle auf inaktiv setzen, und dann beim neu Import wieder auf aktiv Verhindert zumindest das unnötig neue Artikel dazu kommen.

Wenn nun die anderen wirklich gelöscht werden müssen, naja gut dann kann man die inaktiven im nachgang immer noch löschen.

 

[css-umsetzung]

AW: Wawi 107 Performance (Ameise)

Tja, das ist eine Vorgehensweise, die sich schon lange vor meiner Zeit bewährt hat und immer in einer Nacht erledigt war. Es würde aber denke ich auch keinen Unterschied machen, da es ja der Vorgang ist der nun Tage benötigt.

Da ist ein Vergleich, ob ein Artikel vorhanden ist und Aktualisiert oder neu angelegt werden muss, vermutlich in Sachen Performance noch belastender als einfach neue Artikel ohne Prüfung auf vorhanden sein rein zuwerfen.

Leider kann man die Importvorlage nicht kopieren und ich müsste mir diese aufwendig über SQL holen, sonst würde ich es mal auf meinem Rechner mit einer neuen DB versuchen und auch mit einer Developer SQL Version die alle meine Kerne und den ganzen Speicher verwendet, aber das Mapping für den Import der Artikel zu erstellen ist nervig und wäre in dem Punkt dann mein eigenes Vergnügen.

Aber das mit dem vorab auf Inaktiv stellen wäre bei anderen Kunden schon eine gute Vorgehensweise, ich glaube gesehen zu haben, dass es beim Import eine Funktion gibt die nicht aktualisierte Artikel dann löscht.

 

[Marc Völker]

AW: Wawi 107 Performance (Ameise)

Moin,

oder du nutzt einfach mal den Exportieren button in der Ameise (Vorlagen lassen sich in zwischen ja auch Exportieren / Importieren)

Naja aufwendiger? Mehr Last? Wenn man natürlich hingeht erst alles auf inaktiv per Ameise setzt und dann neu Importiert, joar dann schon. Das Prüfen auf vorhanden sein, ist nur ein Select, das wird so oder so gemacht. Und wenn ich dann mal davon ausgehe, Nur neue Datensätze anfügen...

Ich meine die Ameise hat da keine eigene Funktion nach dem Motto, alles was nicht in der CSV war deaktivieren, macht auch keinen Sinn. Die wenigesten Importe lassen sich mit genau einer CSV Realisieren.

 

[css-umsetzung]

AW: Wawi 107 Performance (Ameise)

Ups,

die Funktion vom Export ist jetzt aber ganz neu sehe es gerade in meiner 1.8.2er oder bin ich so blind, das war das erste was ich geschaut hatte.
Dann werde ich nun mal testen ob das bei mir auch so ist.

 

[css-umsetzung]

AW: Wawi 107 Performance (Ameise)

Ich habe hier jetzt mal ein paar aktuelle Daten, die das vorgehen meines Kunden eigentlich (aus meiner Sicht bestätigen)

Datenbank MS SQL 2012 Developer Version Mandant wurde frisch angelegt.
Rechner i7 / 2700k - SSD Platte - 8GIG RAM
25Mbit Leitung

Artikel CSV 20 000 Artikel je Artikel 1 Bild das übers Netz gezogen wird.

der Import mit Bilder war dermaßen langsam, das ich es gleich beendet habe,
der reine Daten Import der Artikel ohne Bilder lag bei 17 Minuten.

Danach habe ich mal einfach nur den selben Datensatz verwendet und die 20 000 Artikel aktualisiert, hier lag ich bei der doppelten Zeit. Wenn ich das hochrechne auf 260 000 Artikel dann ist das für mich einzusehen, dass der Kunde die Artikel neu einspielt
und vorher die Tabellen mit truncate leert.

zum Schluss habe ich die Bilder eingelesen, nur ein Bild je Artikel und als Referenz die Artikelnummer verwendet.
hier lag ich dann bei zusätzlichen 42 Minuten.

Ich behaupte dass der Import durch das gleichzeitige einspielen der Bilder extrem verlangsamt wird und es besser ist diese als letztes einzuspielen.

Eine normale Express Datenbank wird natürlich um einiges langsamer sein denke ich, werde ich aber auch noch testen um einen direkten Vergleich zu haben.

 

[Marc Völker]

AW: Wawi 107 Performance (Ameise)

Hast ne PN, werde gleich gerne nochmal kurz runterschreiben warum das eine sehr schlechte idee ist.

 

[testjo]

AW: Wawi 107 Performance (Ameise)

Stichwort weiter: sehe SSD und alles dazu wie man dan alles einstellen/ändern soll ( gibt whitepapers dazu), weiter welche SSD's man überhaupt in solche situationen benuzten soll.

Und Bilder hmm was macht er dan mit den SHopabgleich, und auch dazu den bilderlinks google und co weiterleitungen und so mehr ??

Express hat weitere nachteilen ofcourse