Neu Hilfe - Performanceproblem mit Shop durch Worker

[xadoX]

Wir sind am 11.03. auf JTL Shop 5.2.4 umgestiegen. Wir nutzen die Wawi 1.8.11.1.
Immer wenn wir mit dem Worker Artikel abgleichen, egal ob Quick Sync oder Komplett kommt unser Server bei All-Inkl. damit nicht klar.
Im Folgenden Fenster sieht man schön, wann der Worker an war. Nämlich nachts bis 5 Uhr, dann mittags nochmal mit JTL zusammen und dann wieder abends.



Das Problem tritt erst beim Artikelabgleich auf. Abholen von Aufträgen klappt.

All-Inkl. hat den Server auf den Kopf gestellt, findet aber keine Probleme

Details zum Shop:
PHP 8.2.16
MySQL 10.6.16 MariaDB
Redis aktiv
memory_limit 512M
max_execution_time 512
post_max_size 200M
upload_max_filesize 200M

256GB RAM
2 TB NVME SSD
2x Intel® Xeon®
2x12 Prozessorkerne
48 mit Hyper-Threading

Einträge in tartikel: 233.001
Einträge in tartikelMerkmal: 2.326.972
Einträge in tartikelAttribut: 2.004.992
Einträge in tbild: 420.600

Was wurde bisher erfolglos geprüft:

- Cloudflare ausgeschaltet
- Cache ausgeschaltet
- Übertragungsparameter angepasst
- Manuellen und Automatischen Abgleich durchgführt
- dbeS Pfad bei Cloudflare für die IP vom Server der JTL-Wawi gewhitelistet
- Wawi und Shop-Logs auf Fehler überprüft


JTL Ticket ist erstellt, da wird sich aber gerade die ganze Zeit der Ball zwischen dem Wawi-Team und Shop-Team hin und her geschoben: #202403113602865

Hat jemand ähnliche Probleme und ggf. Lösungsvorschläge?

-- Ergänzung: 19.03.24

Während des Abgleichs taucht folgender SQL recht häufig auf. Zwar laufen diese SQL's nicht lange, aber das ist noch etwas was nun aufgefallen ist.

SELECT tartikel.kArtikel FROM tkategorieartikel, tartikel LEFT JOIN tartikelsichtbarkeit ON tartikel.kArtikel = tartikelsichtbarkeit.kArtikel AND tartikelsichtbarkeit.kKundengruppe = 1 WHERE tartikelsichtbarkeit.kArtikel IS NULL AND tartikel.kArtikel = tkategorieartikel.kArtikel AND tkategorieartikel.kKategorie = 2713 LIMIT 1

 

[gigi80]

Wawi Update auf 1.8.12.2 machten. Hier wurde ein Woker Bug behoben. vllt hilft dir das schon.

 

[xadoX]

Wawi Update auf 1.8.12.2 machten. Hier wurde ein Woker Bug behoben. vllt hilft dir das schon.

Ich kann dazu im Changelog nichts finden:
https://www.jtl-software.de/jtl-wawi-download/changelog?fromVersion=1.8.11.1&toVersion=1.8.12.2
Hast du hier mehr Informationen?

 

[gigi80]

aus dem Ticket von JTL erfahren

 

[xadoX]

Hattest du auch Probleme mit dem Shop oder nur mit dem Worker?

 

[gigi80]

Eher nur das der Worker beim ersten schritt hängt.

 

[John]

Wenn das Problem nicht gelöst wird - und danach siehts ja im Moment aus: Wieso wird da jede Nacht so viel abgeglichen?

Ich hatte mal einen ähnlichen Fall, in dem ein Kunde andauernd Daten zum Shop schickte. Das warem 100.000de Datensätze, die aber bei detailierter Betrachtung unnötig, weil unverändert waren. Wir haben das dann vorher auf tatsächlich notwendige Änderungen reduziert und gut wars.

 

[xadoX]

Wenn das Problem nicht gelöst wird - und danach siehts ja im Moment aus: Wieso wird da jede Nacht so viel abgeglichen?

Ich hatte mal einen ähnlichen Fall, in dem ein Kunde andauernd Daten zum Shop schickte. Das warem 100.000de Datensätze, die aber bei detailierter Betrachtung unnötig, weil unverändert waren. Wir haben das dann vorher auf tatsächlich notwendige Änderungen reduziert und gut wars.

Wir haben ein Shop-Update von 4 auf 5 hinter uns und da müssen leider alle Variationsbilder einmal neu zum Shop geschickt werden. Daher war/ist ein Komplettabgleich notwendig.

 

[liquid]

Wir haben ein Shop-Update von 4 auf 5 hinter uns und da müssen leider alle Variationsbilder einmal neu zum Shop geschickt werden. Daher war/ist ein Komplettabgleich notwendig.

... aber doch nicht jede Nacht, das ist doch dann ein einmaliger Vorgang.

 

[xadoX]

... aber doch nicht jede Nacht, das ist doch dann ein einmaliger Vorgang.

Genau, aber er gleicht halt extrem langsam ab, weshalb es nun mal mehrere Nächte benötigt. Das ist aber gar nicht das hier beschriebene primäre Problem. Mein Problem ist, dass der Abgleich den Shop in die Knie zwingt. Und das darf einfach nicht sein.

 

[NoOne]

Falls das an den Artikelbildern liegt, dann ist *vielleicht* ImageMagick das Problem. Ich hab da mal von einem Problem gehört, dass ImageMagick beim Konvertieren unter Umständen die temporären Dateien extremst aufbläht, auf mehrere hundert MB bis zu mehreren GB. Man kann die Größe der temporären Dateien in der Konfiguration von ImageMagick beschränken. Je nachdem wie aktuell die Version bei all-inkl ist, ist das ggf. ein Problem. Man könnte das auch zum testen ggf. mal deaktivieren. Der Shop hat einen Fallback dafür, wenn ImageMagick nicht aktiv ist, wird GD benutzt. Ich glaube aber, die endgültigen Bilddateien, die GD generiert sind leicht größer als die, die ImageMagick generiert.

 

[xadoX]

Danke für den Input. Leider treten die Probleme nur beim Artikeldatenabgleich auf. Bilder laufen unglaublich schnell und ohne Probleme durch.

 

[css-umsetzung]

Du solltest mal das dbeS/tmp Verzeichnis über den ftp beobachten, ob die Dateien sich einfach nur anhäufen und abgearbeitete Dateien nicht gelöscht werden.
Gerade wenn der Abgleich manuell ausgeführt wird kann das in vereinzelten Versionen zu einem Problem werden (ich hab das in einer 1.8er nicht getestet)

 

[xadoX]

@css-umsetzung unser Komplettabgleich ist heute morgen endlich durchgelaufen. Der tmp-Ordner ist nun auch leer. Aber die Performanceprobleme im Shop treten weiterhin auf, wenn der Artikeldatenabgleich losläuft.
Auffällig bleibt allein der dann vermehrt auftretende SQL:

 SELECT tartikel.kArtikel FROM tkategorieartikel, tartikel LEFT JOIN tartikelsichtbarkeit ON tartikel.kArtikel = tartikelsichtbarkeit.kArtikel AND tartikelsichtbarkeit.kKundengruppe = 1 WHERE tartikelsichtbarkeit.kArtikel IS NULL AND tartikel.kArtikel = tkategorieartikel.kArtikel AND tkategorieartikel.kKategorie = 2713 LIMIT 1

Dieser läuft zwar max 1-2 Sekunden, jedoch sind davon einige zu sehen. Ist der Abgleich beendet, dann taucht dieser SQL auch nicht mehr auf.

 

[css-umsetzung]

Dieser eine Query braucht 1-2 Sekunden?
Das würde ich ja mal direkt im phpmyadmin testen.

Das ist jetzt auch kein Query, den ich bei einem Abgleich erwarten würde, sondern nur, wenn ein Artikel im Shop aufgerufen wird und ja für jeden Artikel würde das mit eingeschaltetem cache nur einmal passieren.

 

[xadoX]

Dieser eine Query braucht 1-2 Sekunden?
Das würde ich ja mal direkt im phpmyadmin testen.

Das ist jetzt auch kein Query, den ich bei einem Abgleich erwarten würde, sondern nur, wenn ein Artikel im Shop aufgerufen wird und ja für jeden Artikel würde das mit eingeschaltetem cache nur einmal passieren.

Führe ich ihn jetzt aus, wo kein Abgleich läuft, dann ist er in 0.0429 Sekunden durchgelaufen. Während des Abgleichs haben ich davon aber dauerhaft ca. 15-20 parallel laufen.
Der SQL kommt in der includes/src/Helpers/Category.php und includes/src/Helpers/Product.php vor.

 

[mvh]

Führe ich ihn jetzt aus, wo kein Abgleich läuft, dann ist er in 0.0429 Sekunden durchgelaufen. Während des Abgleichs haben ich davon aber dauerhaft ca. 15-20 parallel laufen.
Der SQL kommt in der includes/src/Helpers/Category.php und includes/src/Helpers/Product.php vor.

Moin.
Das Problem kenne ich in 5.2.
Ich habe dann EXTRA die Tabelle manuell geleert
(weil wir keine Artikel für bestimmte Kundengruppen sperren oder freigeben)
und festgestellt, dass der Shop danach bestens funktioniert.

 

[xadoX]

@mvh Welche Tabelle hast du geleert?

 

[mvh]

@mvh Welche Tabelle hast du geleert?

tartikelsichtbarkeit
Diese steuert Artikel "nicht anzeigen" für die Kunden-Gruppen.

 

[xadoX]

Leider ist die Tabelle bereits leer bei uns.