Gelöst Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

[bork]

Hallo,

ich hatte die Problematik schonmal angesprochen: Für die Synchronisation wird ja die Tabelle jtl_connector_link durchsucht und mit den Kunden-, Artikel- und Bestelltabellen gejoint. Die ersten Artikelabgleiche gingen richtig fix, aber als ich dann die jtl_connector_link Tabelle mit Blinddaten für Kunden und Bestellungen bespielt hatte, ging das System in die Knie. Die jtl_connector_link ist mit über 3 MB jetzt schon größer als unsere Kundentabelle. 30.000 Einträge sind da schon drin. Kann das der Grund dafür sein, dass das Synchronisationsstatusfenster in der JTL Wawi erstmal ziemlich exakt 2 Minuten lang komplett einfriert (keine Rückmeldung) bevor die Synchronisation startet? Ich brauche z.B. um 2 Kunden und 2 Bestellungen zu importieren erst die obligatorischen 2 Minuten Wartezeit in denen nichts passiert und dann nochmal 4 Minuten für den Import selbst. Kann das sein, dass diese 2 Minuten Vorlaufzeit die Zeit für das Durcharbeiten der jtl_wawi_connector Tabelle ist, um zu ermitteln, welche Daten überhaupt übermittelt werden sollen? Wenn das so ist, graut es mir vor der Situation, wenn die Tabelle mal doppelt so groß wird. Ein JTL Servicepartner hat mir auch von einem Kunden erzählt, der über 200.000 Kunden hat und bei dem der Connector erstmal über eine halbe Stunde Vorbereitungszeit hat, bevor irgendwas importiert wird. Eine Alternative wäre ja, z.B. in der Connector-Installation Mindestwerte festzulegen, also z.B. Bestellnummern unter 15.000 und Kundennummern unter 10.000 ignorieren. Dann könnte man die jtl_connector_link ja schonmal um über 80 % verkleinern.

Wäre hier ein Ansatzpunkt?
https://gitlab.jtl-software.de/jtl-.../Connector/Gambio/Mapper/CustomerOrder.php#L8


LEFT JOIN jtl_connector_link l ON o.orders_id = l.endpointId AND l.type = 4
WHERE l.hostId IS NULL and o.orders_id > [vorkonfigurierte Mindest-Order ID]",

 

[fav-hosting.online]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hi,

wir hatten ein ähnliches Problem bei Magento und konnten dies bei uns auf fehlende Indexe zurückführen.
Hast du mal die Abfragen die solange dauern mit "EXPLAIN" davor ausgeführt und geprüft ob diese einen Index verwenden bzw. wie lange deren Ausführung dauert?

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hallo Mike,

danke für den Tipp!
Also diese Abfrage hier: https://gitlab.jtl-software.de/jtl-...Connector/Gambio/Mapper/CustomerOrder.php#L54

SELECT o . *
FROM orders o
LEFT JOIN jtl_connector_link l ON o.orders_id = l.endpointId
AND l.type =4
WHERE l.hostId IS NULL
LIMIT 0 , 30

dauert schon 55 Sekunden im phpMyAdmin. Explain liefert mir dies:



Hast du einen Tipp?

 

[fav-hosting.online]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hi,
ich würde versuchen in der Tabelle jtl_connector_link einen Index für die Spalten type und hostID anzulegen.

ALTER TABLE `gambio`.`jtl_connector_link` ADD INDEX GambioTest (`type`, `hostId`);

Danach dann die Abfrage nochmal ausführen und prüfen ob in der Spalte "Key" der verwendete Index GambioTest oder immer noch NULL steht.

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

ich würde versuchen in der Tabelle jtl_connector_link einen Index für die Spalten type und hostID anzulegen.

Wenn der Connector auf vorgesehenem und von uns beschriebenen Weg installiert wurde, dann müssen auch alle Felder einen Index haben.
Ein manuelles abändern der Tabellen dürfte nicht notwendig sein...

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Habe die jtl_connector_link erstmalig regulär über das Installations-Interface installiert, dann möglicherweise zum Reset nur Tabelle geleert, nicht gelöscht. Gab es denn vielleicht seit Dezember 2015 mal eine Installationsversion, bei der die Indices nicht gesetzt wurden? Werde dann mal probieren, die Indices von Hand nachzusetzen. Kaputtmachen kann ich damit nichts, richtig?

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Nein, solange die Daten selbst drin bleiben kann da nichts kaputt gehen.
Die Indizes sollten auf jeden Fall angelegt sein, sonst kann es wirklich zu massiven Performance-Problemen kommen.

 

[fav-hosting.online]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hi Daniel,

hab mir die Tabellen eben nochmal angeschaut, ich denke der Fehler liegt in einer falsch gestalteten Abfrage.
Wie du auf dem Foto von bork sehen kannst wird bei beiden abgefragten Tabellen keine Index bzw. Schlüssel verwendet was bei größeren Tabellen einfach nicht sein darf.
Auch bei meiner Testinstallation in der alle Indexe korrekt gesetzt sind wurden keine Schlüssel verwendet.
Es sollte die Abfrage "l.hostId IS NULL" durch "l.hostId = 0" ersetzt werden da die Spalte keine Nullwerte zulässt wäre hier die Suche nach 0 und nicht nach NULL korrekt.
Diese Änderung bewirkte schon das Gambio ab jetzt einen Index verwendet und die Abfrage bei mir mit 5000 Datensätzen statt 9,9 nur noch 0,0007 Sekunden dauerte.

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Es sollte die Abfrage "l.hostId IS NULL" durch "l.hostId = 0" ersetzt werden da die Spalte keine Nullwerte zulässt wäre hier die Suche nach 0 und nicht nach NULL korrekt.

Das ist leider überhaupt nicht korrekt.
Bei einer derart geänderten Abfrage würdest du grundsätzlich überhaupt keine neuen bzw. noch nicht gemappten Datensätze bekommen.
Die hostId ist das Ergebnis eines Joins auf die Mapping-Tabelle. Das IS NULL auf diesem Feld dient also dazu, festzustellen ob überhaupt schon ein Mapping-Eintrag existiert.
Mit einem Vergleich auf "gleich 0" ist es somit unmöglich dass du jemals ein Ergebnis bekommst, weil es diesen Zustand nicht geben kann.

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hallo,

habe den Index gesetzt. Dachte erst das hätte viel gebracht auf den ersten Blick, aber jetzt sinds doch wieder 54 Sekunden Laufzeit für die Abfrage im phpMyAdmin. Habe ich was falsch gemacht?

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Ich sehe da spontan keinen Fehler. Bei der Anzahl an Einträgen ist es aber auch nicht verwunderlich dass die Abfrage eine Weile dauert.
Wie sind denn überhaupt deine Server-Spezifikationen?
Des weiteren ist es merkwürdig dass deine Link-Tabelle anscheinend mehr Einträge enthält als es tatsächliche Bestellungen gibt?

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Habe gerade mal die Zahl der Einträge manuell verglichen: 13844 Bestellungen in der Link-Tabelle, 13841 in der orders-Tabelle. Das ist in der Tat seltsam. Dann muss ich mal in der Link-Tabelle alle Einträge mit type 4 löschen, die nicht in der orders Tabelle vorkommen? Doppelte Einträge in der jtl_connector_link und der orders Tabelle gibt es jedenfalls nicht, sagt mir
SELECT endpointID, COUNT(*) c FROM jtl_connector_link where hostId = 4 GROUP BY endpointId HAVING c > 1; und
SELECT orders_id, COUNT(*) c FROM orders GROUP BY orders_id HAVING c > 1;

Ach so, wir löschen ja auch mal Bestellungen vom Admin aus, z.B. fehlgeschlagene/doppelte Paypal-Käufe, abgelehnte Rechnungskauf-Käufe oder Testbestellungen. Daher könnte das kommen, oder?

Server-Spezifikationen: All-Inkl Business-Tarif mit max. 30 Kunden pro Server: Webhosting Tarif ALL-INKL BUSINESS - ALL-INKL.COM Eigentlich ist der recht ruhig, und mit 24,95 EUR / Monat kein Billig-Webspace. Über die Server-Spezifikationen machen die aber keine Aussagen, aber da schon standardmäßig PHP 5.6 läuft, ist er vermutlich noch nicht so alt.

VG
bork

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Ach so, wir löschen ja auch mal Bestellungen vom Admin aus, z.B. fehlgeschlagene/doppelte Paypal-Käufe, abgelehnte Rechnungskauf-Käufe oder Testbestellungen. Daher könnte das kommen, oder?

Richtig, das wäre auf jeden Fall eine Erklärung. Wenn im Shop-Backend gelöscht wird verbleiben zuvor gezogene Mapping-Einträge natürlich.

All-Inkl Business-Tarif mit max. 30 Kunden pro Server: Webhosting Tarif ALL-INKL BUSINESS - ALL-INKL.COM Eigentlich ist der recht ruhig, und mit 24,95 EUR / Monat kein Billig-Webspace.

Naja, klar, günstiger geht es immer. Aber für 24,95 würde ich persönlich dennoch keinen Shop hosten. Mit "Business" hat das ja nicht viel zu tun...
Aber gut, ist natürlich auch alles eine Frage der Besuchszahlen und des Durchsatzes.

Der initiale Join ist halt leider verhältnismäßig aufwändig und kann bei der Masse an Einträgen nun mal dauern.
Wenn alle Tabellen geprüft wurden ob die Indizes korrekt sind (also auch die Gambio-eigenen), fallen mir da auch eigentlich nur noch 2 Lösungen ein:
1. Schnellerer Server mit mehr Ressourcen
2. Eigentlich die besser Lösung: Aufräumen. Kommt natürlich nur in Frage wenn es überhaupt möglich ist. Sofern man aber zum Beispiel Daten hat die schon einige Jahre alt sind und ggf. nicht mehr akut notwendig sind, könnte man diese mal backuppen und löschen. Das dürfte der Performance einen ordentlichen Schub geben.

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Danke für die Erklärungen.

Das mit dem Aufräumen ist etwas schwierig: Kundenkonten von älteren Kunden möchten wir nur ungern löschen, und ansonsten bin ich mir unsicher, was die Aufbewahrungspflicht für Geschäftsdokumente betrifft. Ob das auch 10 Jahre oder nur 6 sind bei solchen Daten. Wo würde man denn mit einem Plugin ansetzen, um zu sagen, dass z.B. nur alle orders_ids über 14.000 abgeglichen werden sollen? Hier oder? https://gitlab.jtl-software.de/jtl-.../Connector/Gambio/Mapper/CustomerOrder.php#L8 Das würde auch viel helfen, oder?

Könntet ihr uns ein Angebot für so ein Plugin machen? Dann hätte man für andere Sachen auch ein Original Gambio-Beispiel-Plugin zum besseren Verständnis der Funktionsweise.

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Das mit dem Aufräumen ist etwas schwierig: Kundenkonten von älteren Kunden möchten wir nur ungern löschen

Die Kundenkonten müsst ihr ja nicht löschen. So wie bisher beschrieben, sind es ja eher die Masse an Bestellungen im System die dazu führen dass der Abgleich langsam ist.
In einem ersten Schritt würde es somit vermutlich reichen, nur die orders zu sichern und aus der Live-Datenbank zu löschen.
Alternativ kann man sich ja auch eine zweite Datenbank mit einer exakten Kopie des bisherigen Bestands machen. Sollte dann tatsächlich ein Kunde nach Jahren zwingend nochmal eine Bestellung im Shop nachgucken müssen, kann man die Daten in wenigen Sekunden wieder zurück kopieren.

Wo würde man denn mit einem Plugin ansetzen, um zu sagen, dass z.B. nur alle orders_ids über 14.000 abgeglichen werden sollen? Hier oder? https://gitlab.jtl-software.de/jtl-s...erOrder.php#L8

Ja, es wäre möglich an dieser Stelle den Query abzuändern um vorab noch eine entsprechende Filterung vorzunehmen.
Allerdings muss man dabei bedenken, dass eigene Änderungen direkt im Connector-Code dann auch bei jedem Update wieder von euch nachgezogen werden müssten.
Der korrekte und dauerhaft zuverlässige Weg ist daher natürlich über das Plugin-System des Connectors.

Könntet ihr uns ein Angebot für so ein Plugin machen? Dann hätte man für andere Sachen auch ein Original Gambio-Beispiel-Plugin zum besseren Verständnis der Funktionsweise.

Ein Beispiel für ein Connector-Plugin ist ja im Gitlab vorhanden: https://gitlab.jtl-software.de/jtlconnector/demo-plugin
Ein Angebot kann ich leider nicht machen, da wir selbst keine einzelnen Auftrags-Arbeiten übernehmen. Individuelle Anpassungen und Erweiterungen machen wir nur im Rahmen einer Professional- oder Enterprise-Subscription.

Da das Thema mit älteren Bestellungen aber schon öfter vorkam, werde ich mir mal überlegen was man da "serienmäßig" machen kann.
Wäre es zu dem Zweck eventuell möglich, dass du mir Zugang zu deiner Shop-DB oder einer Kopie davon einrichten könntest? Da du eine enorme Menge an Daten hast, wäre das eine sehr gute Möglichkeit um zu gucken was man Performance-mäßig machen kann...

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Ja, da kann ich gerne eine anonymisierte Kopie der Shop-DB vorbereiten und schicke dann die Zugangsdaten. Oder lieber als SQL Dump per FTP?

 

[daniel.jtl]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Ja, da kann ich gerne eine anonymisierte Kopie der Shop-DB vorbereiten und schicke dann die Zugangsdaten. Oder lieber als SQL Dump per FTP?

Ein Zugang wäre besser. Andernfalls kann man ja nicht prüfen ob es gegebenfalls auch Probleme mit dem Hosting gibt...

 

[bork]

AW: Shop-Synchronisation: Fenster friert 2 Minuten lang ein bevor es losgeht

Hallo,

gibts an dieser Front schon was Neues? Zugangsdaten zu einer anonymisierten Shopkopie hatte ich ja geschickt...

VG
bork