Hallo miteinander, hat irgendjemand eine Idee, außer das ganze System zu wechseln?
Die KI schlagen mittlerweile vor, die Artikel direkt in Shopware zu importieren. Was ja auch nicht zielführend ist.
Das ganze zieht sich jetzt auch wieder bereits seit zwei Wochen. Es findet das übliche Kreiswichsen zwischen JTL, Shopware und Hoster statt.
Alle Tipps, welche von dort gegeben worden sind, sind umgesetzt.
Im Endeffekt hat sich nichts verbessert, außer die Erkenntnis, dass der Connector einfach nicht arbeitet. Ich habe es mal Claude nach umfassenden Prüfungen formulieren lassen, der Support von JTL ist ja nicht zielführend: Wenn man 3 Nachrichten austauscht, ist die Woche vorbei.
Wir haben ein massives Performance-Problem mit dem SaaS Connector beim Artikel-Upload zu Shopware 6.6.
Das Problem: - Der product.push läuft extrem langsam: ca. 30 Artikel in 10 Minuten (in guten Phasen)
Nach jedem Batch (2 Artikel) gibt es lange Pausen, bevor der nächste Batch gesendet wird - Bei ca. 25.000 ausstehenden Artikeln ist das nicht praktikabel
Es kommt regelmäßig zu Timeouts: "Exception bei product.push: Timeout für Vorgang überschritten"
Was wir wissen:
- Shopware API antwortet in unter 100ms (getestet mit direkten API-Calls)
- Der SaaS Connector selbst antwortet in 120ms
- Server: 24 CPU-Kerne, 128 GB RAM, NVMe SSDs
– keinerlei Ressourcenengpässe
- Datenbank zeigt keine aktiven Queries während der Connector "hängt"
– MySQL ist idle
- OpenSearch-Cluster: green, 20 GB Heap, 26% Auslastung
- Redis Messenger Queue: stabil, keine ACK-Fehler
- Wir haben 13 Sprachen pro Artikel konfiguriert
Das Muster:
- Ein Batch mit 2 Artikeln wird gesendet und verarbeitet
- Danach passiert minutenlang nichts
– weder bei Shopware noch in der DB
- Dann kommt entweder der nächste Batch, oder ein Timeout
- Einmal lief der Sync nachts mit ca. 300 Artikeln/Stunde – mit identischer Konfiguration
Unsere Vermutung:
Das Problem liegt nicht bei Shopware oder unserer Infrastruktur, sondern im SaaS Connector selbst – entweder bei der Wartezeit zwischen Batches oder bei der internen Verarbeitung der Responses.
Die KI schlagen mittlerweile vor, die Artikel direkt in Shopware zu importieren. Was ja auch nicht zielführend ist.
Das ganze zieht sich jetzt auch wieder bereits seit zwei Wochen. Es findet das übliche Kreiswichsen zwischen JTL, Shopware und Hoster statt.
Alle Tipps, welche von dort gegeben worden sind, sind umgesetzt.
Im Endeffekt hat sich nichts verbessert, außer die Erkenntnis, dass der Connector einfach nicht arbeitet. Ich habe es mal Claude nach umfassenden Prüfungen formulieren lassen, der Support von JTL ist ja nicht zielführend: Wenn man 3 Nachrichten austauscht, ist die Woche vorbei.
Wir haben ein massives Performance-Problem mit dem SaaS Connector beim Artikel-Upload zu Shopware 6.6.
Das Problem: - Der product.push läuft extrem langsam: ca. 30 Artikel in 10 Minuten (in guten Phasen)
Nach jedem Batch (2 Artikel) gibt es lange Pausen, bevor der nächste Batch gesendet wird - Bei ca. 25.000 ausstehenden Artikeln ist das nicht praktikabel
Es kommt regelmäßig zu Timeouts: "Exception bei product.push: Timeout für Vorgang überschritten"
Was wir wissen:
- Shopware API antwortet in unter 100ms (getestet mit direkten API-Calls)
- Der SaaS Connector selbst antwortet in 120ms
- Server: 24 CPU-Kerne, 128 GB RAM, NVMe SSDs
– keinerlei Ressourcenengpässe
- Datenbank zeigt keine aktiven Queries während der Connector "hängt"
– MySQL ist idle
- OpenSearch-Cluster: green, 20 GB Heap, 26% Auslastung
- Redis Messenger Queue: stabil, keine ACK-Fehler
- Wir haben 13 Sprachen pro Artikel konfiguriert
Das Muster:
- Ein Batch mit 2 Artikeln wird gesendet und verarbeitet
- Danach passiert minutenlang nichts
– weder bei Shopware noch in der DB
- Dann kommt entweder der nächste Batch, oder ein Timeout
- Einmal lief der Sync nachts mit ca. 300 Artikeln/Stunde – mit identischer Konfiguration
Unsere Vermutung:
Das Problem liegt nicht bei Shopware oder unserer Infrastruktur, sondern im SaaS Connector selbst – entweder bei der Wartezeit zwischen Batches oder bei der internen Verarbeitung der Responses.