In Bearbeitung Shop benötigt sehr lange für den Sync wegen folgender SQL Abfrage:

[reacend]

Hi,
Kann mir jemand sagen warum das sql Query so lange dauert?
Das hält den ganzen Shop Sync auf:

SELECT * FROM customers c LEFT JOIN address_book a ON c.customers_default_address_id = a.address_book_id LEFT JOIN countries co ON co.countries_id = a.entry_country_id LEFT JOIN jtl_connector_link l ON c.customers_id = l.endpointId AND l.type = 2 WHERE l.hostId IS NULL && c.customers_status != 0 ORDER BY c.customers_date_added LIMIT 100

 

[reacend]

Es hängt definitv mit der Tabelle: jtl_connector_link zusammen, die aht auch knapp 70mb

 

[daniel.jtl]

Dann hast du eine Version des Connectors die seit mindestens 7 Monaten veraltet ist. In allen darauffolgenden Versionen sind die Link-Tabellen nach datentyp unterteilt, wodurch die Performance deutlich besser ist.
Davon abgesehen hilft es natürlich enorm Altlasten zu bereinigen, und möglicherweise nicht mehr benötigte oder veraltete Daten zu sichern und zu entfernen.
Nicht zuletzt ist auch die Performance und Konfiguration des Hostings entscheidend.

 

[reacend]

hi,
ja nur die frage ist, lösche ich die ganze tabelle oder laufe ich da gefahr das die kunden neu importiert werden und cih Sie doppelt habe?

Den Connector zu updaten kommt derzeit nicht in frage, da wir eh auf nen JTL SHOP UPdaten möchten und der XTC MOdified in der version 1.06 ist.

 

[daniel.jtl]

Es dürfen dann natürlich nur Daten bereinigt werden die auch nicht mehr benötigt werden, es sollen ja nicht die gesamten Tabellen geleert oder gelöscht werden.
Und das muss ja parallel geschehen, also nicht nur die Mappings, sondern vor allem die dazugehörigen Daten (also Bestellungen, Kunden, etc.).

Wenn aber eh zukünftig ein JTL Shop eingesetzt werden soll, würde ich da jetzt nicht zwingend noch Experimente anfangen...

 

[foo007]

Wir haben das gleiche Problem, bei uns dauert es 15-30 Min. ... das ist grauenhaft ... was können wir machen ohne gleich das ganze System zu wechseln ?

 

[Teratek]

Ist bei uns das selbe Problem. Am besten erstmal nach Datenleichen suchen damit die Tabellen kleiner werden

 

[Tombstone]

Nee am Besten den Connector entpacken,
in die Customer.php und die CustomerOrder.php ein Limit der SQL Abfrage einsetzen!

z.B. für die CustomerOrder.php wobei xxxxx eine der letzten bereits übertragenen Bestellnummern ist.

"table" => "orders",
"query" => "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 && o.orders_id >= xxxxx",

und dann die entsprechenden Indexeinträg aus der jtl_connector_link Tabelle mit dem Typ 4 welche VOR der xxxxx sind löschen.

BITTE VORHER EINE SICHERUNG DER ENTSPRECHENDEN TABELLE ERSTELLEN!

SELECT *
FROM `jtl_connector_link` WHERE type = 4
ORDER BY `jtl_connector_link`.`type` ASC

analog das ganze mit der Customer.php und das ganze wird wieder super schnell.

Die Teilung der jtl_connector_link Tabelle währe dann optional der 2. Schritt !!!

 

[foo007]

also Daten zu löschen ist keine schöne Lösung, denn die Kunden möchten ja mindestens 1 Jahr lang die Bestellhistorie sehen und nutzen.
Gibt es eine elegantere Lösung ? Sowas wie: Bereits übertragene Daten ignorieren damit das System nicht unnötig belastet wird ?

 

[Teratek]

so war das nicht gemeint mit dem löschen. Doppelte Kunden entfernen schon eher

 

[Tombstone]

Ja meine im Post #8 dort werden keine Daten aus dem Shop gelöscht!
Es werden bereits synchronisierte Aufträge und Kunden aus der jtl_connector_link entfernt und damit die nicht nochmal in die Wawi importiert werden - ein Limit (Abbruchschranke) definiert ab der eingelesen wird.

Das geht aber nur mit entpacktem Connector (UNPHAR)

 

[daniel.jtl]

und dann die entsprechenden Indexeinträg aus der jtl_connector_link Tabelle mit dem Typ 4 welche VOR der xxxxx sind löschen.

Abgesehen davon, dass ein neuerer Connector das ja seit über einem halben Jahr serienmäßig könnte:
Der Vorschlag ist nicht ganz falsch, allerdings fehlt hier der wichtige Hinweis dass die order_ids nicht grundsätzlich automatisch in der richtigen Reihenfolge kommen müssen.
Hat man die also mal nicht perfekter Reihenfolge in der DB stehen, gehen unter Umständen Daten verloren.

Das geht aber nur mit entpacktem Connector (UNPHAR)

Oder wesentlich sinnvoller: Einfacher den Quellcode direkt runterladen: https://gitlab.jtl-software.de/jtl-software-gmbh/jtl-modified-connector
Ein Phar zu entpacken ist grundsätzlich keine gute Idee...

Aber ganz ehrlich: Den Connector einfach zu updaten wäre hundertfach einfacher und effizienter...

 

[Teratek]

bekommt man noch iwo die 1.6er Version für modied 1.06 als Quellcode?

 

[daniel.jtl]

bekommt man noch iwo die 1.6er Version für modied 1.06 als Quellcode?

Klar, indem man einfach in Gitlab die History nutzt.
1.6 zum Beispiel hier: https://gitlab.jtl-software.de/jtl-...49761d3d0a5507ec3a45ff74bb59754a9/archive.zip

Mir ist allerdings vollkommen unverständlich warum man Code nehmen möchte der seit 2 Jahren veraltet ist, wo mittlerweile diverse Dinge nicht mehr kompatibel sind und auch dutzende Fehler zwischenzeitlich beseitigt wurden.

 

[foo007]

Aber ganz ehrlich: Den Connector einfach zu updaten wäre hundertfach einfacher und effizienter...

heißt das in er aktuellen Version 1.6 (für modifed 1.06) das Problem mit der Performance behoben ist ?

Wie kann ich sehen welche Version ich nutze ?

 

[daniel.jtl]

1.6 ist nicht aktuell, sondern 2 Jahre alt.
Die aktuelle Version (wie auch im Kundencenter und hier im angepinnten Beitrag erkenntlich) ist die 1.8.
Das Performance-Problem ist dort längst behoben.

Diese Version sollte theoretisch auch mit 1.06 funktionieren, wurde aber nicht von uns damit offiziell getestet.
Alles unter 2.0 wird aufgrund des nicht mehr tragbaren Alters und aus Sicherheits-Gründen nicht mehr von uns supported.

 

[foo007]

wurde aber nicht von uns damit offiziell getestet.

Gibt es jemanden der das inoffiziell getestet hat oder evtl. im Einsatz hat ?

 

[reacend]

also, mit folgendem query habe ich die datenbank bereinigt:
DELETE FROM `jtl_connector_link_NEW` WHERE endpointid not RLIKE '^[0-9]+$' AND type = 2

eventuell hilft es ja jemandem Aber vorher alles mal Sichern.

PS: Die kunden hat er dann importiert aber es sind keine doppelt im JTL

 

[Tombstone]

@daniel.jtl

ich hab mal testweise den JTL Connector 1.8 heruntergeladen und in einem TestShop Modified 1.06 installiert.
Die neuen/einzelnen jtl_connector_link_TYPE Tabellen werden auch über die Installer.php angelegt aber nicht mit dem db/updates/1.7.php aus der alten jtl_connector_link befüllt und die Tabelle gesichert/umbenannt.

Wann bzw. wie wird diese Datei ausgeführt ? Beim ersten Abgleich mit der Wawi vielleicht ?

 

[daniel.jtl]

Die Migration der Datenbank läuft nur wenn im db Ordner eine Datei namens "version" liegt, die als Inhalt eine vorhergegangene Versionsbezeichnung enthält (zb halt"1.6").