Neu Connector 1. Abgleich von modified-Shop zu JTL-Wawi mit ~300.000 Artikeln

[Kito123]

Hallo,
wir haben unsere Wawi von der Version 0.99923 auf 1.0 und dann auf 1.3.20.0 geupdatet. An der Wawi sind 3 modified-Shops angebunden. Prinzipiell funktioniert die neue Wawi und auch die Connectoren zu den Shops.
Unser Dienstleister hat aber die alten Connectoren gelöscht und neue erstellt. Dadurch ist die Zuordnung der Bestellungen/ Rechnungen zu den Shops auch gelöscht worden. Das ist nicht schön, aber damit kann man irgendwie leben.

Unser Problem ist jetzt, dass ein Shop mit ~300.000 Artikeln einen 1. Abgleich machen muss. Die Artikel sind sowohl im Shop als auch in der Wawi vorhanden, es gibt aber keine Verknüpfung der beiden. Das wiederherstellen der Verknüpfungen dauert extrem lange bzw. bricht immer wieder so ab ca. 30.000 Artikeln ab.
Als ersten Lösungsansatz haben wir jetzt lokal einen Webserver mit einer Kopie des Shops erstellt. Nun findet der Abgleich nicht zum Shop im Internet, sonderen bei uns lokal im Netzwerk statt. Wir sind gerade bei ca. 50.000 Artikeln und es wird immer langsamer. Nach unseren Hochrechnungen sind wir bereits bei ca. 11 Tagen. Allerdings wird die Zeit masiv länger, je mehr Artikel im Shop sind.

Dieser Query dauert bereits über. 8 Min. je 100 Artikel und ist soweit ich es verstehe das was am längsten dauert:

SELECT p.* FROM products p
LEFT JOIN jtl_connector_link_product l ON p.products_id = l.endpoint_id
WHERE l.host_id IS NULL LIMIT 100

Momentan verlängert sich die Ausführdauer des Query um ca. 1Min je 5.000 Artikel.

Gibt es hier irgend eine andere Möglichkeit den 1. Abgleich zu realisieren?

Unser Dienstleister ist hier wie es scheint mit seinem Latein leider am Ende...

 

[Thomas Lisson]

Hi,
welche Indizes hat die Tabelle jtl_connector_link_product bei dir?

 

[Kito123]

Hallo Thomas,
vielen Dank für deine schnelle Antwort!

endpoint_id ist der primarykey
und host_id hat einen "normalen" Key.

Anbei ein Screenshot:

 

[Kito123]

Hier noch der Create Code:

CREATE TABLE `jtl_connector_link_product` (
    `endpoint_id` VARCHAR(20) NOT NULL COLLATE 'utf8_unicode_ci',
    `host_id` INT(20) NOT NULL,
    PRIMARY KEY (`endpoint_id`),
    INDEX `host_id` (`host_id`)
)
COLLATE='utf8_unicode_ci'
ENGINE=InnoDB
;

 

[z0mbi3]

Wir sind damals über ein gleiches Problem gestoßen, das es immer langsamer geworden ist. Wenn du die JTL Tabellen vergleichst, wird dir auffallen, das VARCHAR hier eigtl. falsch ist. das muss auch ein INT sein, da die Produkt Id im Modified Shop auch nur INT ist. Bei VARCHAR muss Mysql immer umkonvertieren, was dann ewig dauert.

Das Problem müsste mal an den Connector Verantwortlichen geleitet werden, weil es erst ab bestimmen Mengen sich bemerkbar macht.

 

[Kito123]

Aktueller Stand ist so:
- Je nach MYSQL (Shopseitig) wird der 1. Abgleich ab ca. 30.000 Artikel richtig langsam. Wir haben unseren Abgleich noch mal abgebrochen um die Performance des MYSQL Servers zu erhöhen. Der MYSQL hat jetzt 4 Kerne mit 32GB Ram und ist rein für MYSQL zuständig. Eine zweite Maschine ist für PHP/ Apache zuständig, hat 4GB RAM > 2GB für PHP. Auf der 3. Maschine läuft Windows 2012 und MSSQL 2014, 24GB RAM, davon 8GB für die Wawi DB.

Alle Maschinen laufen lokal bei uns im LAN. Dazu haben wir den Shop lokal kopiert. Der Shop läuft im Netz ohne Wawi. Sollte die Wawi Synchronisierung jemals klappen, kopieren wir die Connector-Tabellen in den Live-Shop und ändern die Connector-Einstellungen auf den Shop im Netz. - Das wäre der Plan... Dazu kommt noch, dass wir die beteiligten Tabellen von MyISAM nach INNODB geändert haben (die Connector Tabellen waren schon INNODB, aber die products usw. waren vorher MyISAM. Ob das was bringt weiß ich auch nicht...)

Nach meinen Erfahrungen gibt es in der MYSQL einen riesigen Flaschenhals in der Leistung jeder einzelnen CPU. MYSQL kann soweit ich es verstehe eine Anfrage nur auf einer CPU ausführen. Für diesen Anwendungsfall ist das ein Problem. In der Regel werden Datenbanken von verschiedenen Nutzern mit parallelen Anfragen genutzt. Hier kann die Last auf mehrere CPU's verteilt werden. Läuft aber nur eine Anfrage, die extrem lange läuft muss diese Anfrage von einer CPU abgearbeitet werden. Unser 4 Kern Linux MYSQL Server hat eine permanente Auslastung von ~ 25%.
- Für dieses Problem habe ich leider keine Lösung.

Performance erhöhen + Warten (ca. 14 Tage) kann man als User leider nicht.

- Ich vermute eine ungünstige Gestaltung der SQL-Querys auf der Seite des Connectors die sich eben ab ca. 30.000 Artikel bemerkbar macht. Hier gäbe es sicher cleverere Lösungen. Für mein laienhaftes Verständnis ist es so, dass die Wawi-Artikel-ID mit der Modified-Artikel-ID über die Artikelnummer gemappt wird. Dazu kommen zwar noch weitere Abfragen zwecks Bestand usw. aber das kann ja nicht so lange dauern...

Der JTL-Support hat sich freundlicherweise auch dazu gemeldet - erst mal vielen Dank dafür - aber leider sieht es so aus, dass es dafür aktuell - außer warten und mehr Leistung - keine Lösung gibt.

 

[z0mbi3]

@Kito123 Hast du das mit dem VARCHAR zu INT mal getestet? Glaub das wird deine Lösung sein. Nicht die Queries sind das Problem, eher wie die Tabellen vom Connector festgelegt werden und wie gesagt ist dort meiner Meinung nach ein Fehler drin, wenn für die Id, welche den Datentyp INT (Zahl) hat, der Datentyp VARCHAR (Zeichenkette) genutzt wird. Dann ist klar, warum das Query dann auch immer länger brauch je mehr Daten in den Tabellen sind. Wie gesagt, uns hat es geholfen es auf INT zustellen, so wie es eh auch schon bei den anderen jtl_* Tabellen gemacht wurde. Es ist nur die jtl_connector_link_product Tabelle vom Connector verkehrt.

 

[Kito123]

Hallo z0mbi3,
super!!! das war die Lösung. Jetzt's geht'ts ab..
Das habe ich mir nicht vorstellen können, dass diese Konvertierung so lange dauert, aber das war definitiv der Flaschenhals!

Vielen herzlichen Dank!

 

[z0mbi3]

Hallo z0mbi3,
super!!! das war die Lösung. Jetzt's geht'ts ab..
Das habe ich mir nicht vorstellen können, dass diese Konvertierung so lange dauert, aber das war definitiv der Flaschenhals!

Vielen herzlichen Dank!

Cool das es bei euch auch klappt. Falls du ein offizielles Ticket bei JTL dazu hast, gib am besten die Info weiter an den Support von JTL, damit das im Connector korrigiert wird.

 

[Kito123]

Deine Lösung habe ich schon an das Ticket gemeldet