Shopware 6 API für großen Produktkatalog unbenutzbar?

Moin!

Hier erstmal die Kurzfassung dieses Posts: Wir (versuchen) unseren Shop & Schnittstelle mit hunderttausenden Artikeln und Kategorien von Shopware 5 auf 6 (alles CE & self-hosted) zu migrieren und stoßen auf massive Performanceprobleme. Wer betreibt noch große Shops und hat hiermit Erfahrung?

Hier die lange Version mit Vorgeschichte und mehr technischen Details:
Wir nutzen schon lange Shopware für unsere E-Commerce Bedürfnisse, seit Version 4 sind wir dabei. Wir „leiden“ dabei schon immer an der Besonderheit, dass wir ein großes Sortiment an Motorradteilen anbieten, was zu vielen Artikel-zu-Kategorie Zuordnungen führt. Aktuell reden wir von ~100.000 Artikeln und ~60.000 Kategorien, an sich keine große Datenmenge. Die denormalisierten Tabellen wie product_category_tree haben allerdings aktuell 12.000.000 Einträge. Mit Sicherheit nicht wenig, aber heutzutage eigentlich eine Datenmenge, die keine unüberwindbare Herausforderung darstellen sollte.

Unser aktuelles System, welches noch auf Shopware 5 basiert, kommt soweit gut damit klar. Die API antwortet bei vollen Artikelupdates flott und auch der Shop ist noch in einem erträglichen Rahmen benutzbar. Um dort anzukommen war es ein langer Weg von Trial & Error, aber wir sind irgendwann angekommen. Wir haben zig Hoster durchprobiert, hatten Instancen bei AWS, etc pp… am Ende sind wir bei TimmeHosting und dem t91 gelandet (Managed Server mit 32 Kernen, 128GB RAM, NVMe SSD) und sind sehr zufrieden, v.a. der Support hat wirklich enormes Fachwissen. Unser System macht Gebrauch von Elasticsearch und Redis, aber unser Server langweilt sich aktuell eigentlich, selten ist die Maschine mehr als zu einem Fünftel ausgelastet. Pro Monat haben wir zwischen 700.000 und 1.200.000 Seitenaufrufe.

Kommen wir zu unserem aktuellen Problem: Wir bekommen Shopware 6 in der gleichen Umgebung nicht zufriedenstellend performant. Es kommt gut und gerne mal vor, dass wir mehrere zehntausend Artikel am Tag updaten müssen, vor allem hier hat das System große Probleme. Wir haben die maximale Anzahl an zugeordneten Kategorien schon intern auf 5000 Stück begrenzt. Das Updaten aller Attribute von so einem Artikel dauert teils mehrere (!) Minuten, wenn es nicht eh zu anderweitigen Abbrüchen kommt. Das Aufrufen im Adminbereich entsprechender Artikel ist ähnlich fürchterlich, gerne friert der Tab komplett ein.
Alleine durch diese Tatsache können wir unsere Artikel nicht sequentiell updaten, wir haben unsere Schnittstelle entsprechend umgeschrieben, dass es via Multiprocessing arbeitet - nur so haben wir zumindest theoretisch die Chance, der Datenmenge Herr zu werden. In der Praxis funktioniert allerdings auch dieser Ansatz nicht, damit bekommen wir den Server tatsächlich an seine Grenzen und während der Updates ist er unbenutzbar langsam. Das Neuaufbauen vom Elasticsearch-Index fürs Frontend dauert inzwischen auch schon anderthalb Stunden.

Betreibt irgendwer einen self-hosted Shopware 6 Store mit ähnlichen Spezifikationen und kann Tipps zu Frontend- wie Schnittstellenperformance liefern? Wir haben auch kein Problem damit, für Fachwissen zu zahlen, aber auf die Bezahlpläne von Shopware selbst wollen wir uns nicht einlassen. Ist Shopware 6 überhaupt noch das richtige System für unseren Anwendungsfall? Wir würden uns über einen sachlichen Erfahrungsaustausch freuen!

1 „Gefällt mir“

Habt ihr die Indexierung deaktiviert oder auf asynchron gesetzt?

Shopware 6 nutzt meiner Erfahrung nach an wesentlichen stellen Performance-kritische DAL Abfragen, die in dieser Größe ggf. schon zu Problemen führen können. Das liegt an der Kombination Artikel/Varianten x Kategorien. Da hilft es ggf. nur, die relevanten Stellen zu überschreiben und direkt SQL ausführen zu lassen.

Insbesondere ist die Indexierung ein Performance Killer. Da muss Shopware unbedingt noch einmal ran, DAL raus, SQL rein.

1 „Gefällt mir“

Wir sind auch bei Timme und sehr zufrieden. Shopware 5 ist aktuell bei uns auch schneller als die Testinstanz von Shopware 6.5.5.1.

Daher mal ein paar Fragen bzw. Anregungen:

  • welche Shopware Version genau? Shopware 6.5 ist deutlich schneller als 6.4. Derzeit wird an 6.6 gearbeitet, welches auch wieder schneller sein soll.
  • PHP und SQL Version? Wir nutzen z.B. MariaDB werden aber bald aufgrund der Empfehlung von Shopware auf MySQL 8 wechseln.
  • das schon durchgearbeitet: Performance Tweaks | Shopware Documentation ?
  • Idee bei so vielen Artikeln und Kategorien: wie wäre es mehrere Shops (also mehrere Shopware Instanzen) draus zu machen, um die Anzahl an Artikeln und Kategorien zu verteilen? Der Server müsste das ja locker weiterhin hinbekommen.
  • sicherlich suboptimal aber trotzdem vielleicht machbar: den kleinsten Shopware Plan Rise buchen (läuft glaub ich immer min 1 Jahr) und hier intensiv den Shopware Support nutzen bis dieses Problem und vielleicht noch andere gelöst wurden und dann den Vertrag auslaufen lassen und die Community Edition weiter nutzen.
  • wenn das alles nicht hilft wirklich mal andere Shopsysteme evaluieren. Z.B. soll Magento 2 keine Probleme mit 1 Mio Artikel haben: Can Magento 2 handle 1M products?
2 „Gefällt mir“

Moin, danke für Euren Input!

@area-net-gmbh:
Alles probiert, kein nennenswerter Unterschied festzustellen bzw. der Shop ist immer noch zu langsam, um es irgendwem zuzumuten.

@raymond-de:
Viele gute Tipps, danke Dir! Den Performance Guide haben wir schon durchgespielt, wir verwenden Shopware 6.5.6 mit MySQL 8.0.32. Dass Shopware 6.6.x den großen Boost bringt, kann ich mir nicht vorstellen… außerdem sind wir eh schon hinter dem Zeitplan, wir würden gerne mal wieder produktiv ToDo’s abarbeiten statt so viel Zeit mit Troubleshooting zu verbringen. Da können wir uns es nicht leisten, auf neue Releases zu warten und zu hoffen.

Mehrere Instanzen sind leider auch nicht praktikabel, wir brauchen die Daten zwingend an einem Ort, ohne die Verknüpfung sind die Artikel für den Nutzer wertlos. Wir haben inzwischen überlegt, einfach nur die Artikel und Kategorien für sich alleine stehen zu lassen und die Verknüpfung über einen eigenen Elasticsearch-Index herzustellen… aber das wäre auch ganz schön viel Arbeit für eine halbgare, zusammengehackte Lösung. Dann denke ich lieber „ganz oder gar nicht“.

Die Idee mit dem kleinsten Shopware-Plan ist grundsätzlich nicht doof! Ein bisschen Erfahrung mit dem Support haben wir schon mal gemacht, das ist zwar schon lange her, aber stimmt uns leider auch nicht gerade positiv. Damals fuhren sie ziemliches Minimalprinzip und haben trotz technisch fundierter Nachfragen gefühlt wenig Lust gehabt, einem zu helfen. Da Shopware nun nochmal deutlich härter kommerzialisiert wurde bin ich mir unsicher, ob es nun besser geworden ist…

@ Max_Shop: (man darf nur zwei Benutzer pro Beitrag erwähnen? Macht Sinn…)
Wir würden das Kernsystem gerne unangetastet lassen, wie oben schon erwähnt „ganz oder gar nicht“. Lieber würden wir unsere Zeit in Features stecken, die Usability und Conversions bringen.

Tja, was tun? So langsam zweifeln wir wirklich an der Brauchbarkeit von Shopware 6 für unsere Zwecke, was wir schade fänden. Für kleine Shops (à la „ich mach Dropshipping mit 50 Produkten“) war Shopware ja schon immer tendenziell zu groß und komplex, im Profibereich jedoch großartig. Sauber aufgebaut, einfach zu erweitern, schnell… vieles davon ging gefühlt mit Shopware 6 über Bord, trotz gestiegener Kosten im gesamten Ökosystem. Vielleicht verwenden wir es auch nur falsch, kann und will ich nicht ausschließen. Aus Erfahrung kann ich aber sagen, dass SW5 mit der gleichen Manpower in deutlich kürzerer Zeit in ein brauchbares Fahrwasser gebracht werden konnte.

Wir geben erstmal nicht auf und hoffen noch auf weiteren Input, auch mit Timme werden wir nochmal in Kontakt treten. Parallel werden wir aber auch mal Magento 2 CE installieren und beginnen zu testen.

Ich würde versuchen, die Updates vieler Artikel direkt in der Datenbank durchzuführen und dann auch nur auf die in dem Moment notwendigen Teile (Shopware Tabellen) zu reduzieren z.B. Preis, Bestand. Die Datenbank führt Mengenoperationen im Vergleich zur Einzelsatzoperation (ein Artikel nach dem Anderen) über die API viel, viel schneller aus.

Was müsst ihr denn genau updaten?

  1. Ganzen Artikel inklusive insert und/oder delete wenn es ihn nicht mehr gibt?
  2. Oder nur bestimmte Daten: Preis, Bestand?

Bei zwei wäre es sicherlich relativ performant möglich, dass direkt über die Datenbank upzudaten.

@marco.steinhaeuser Vielleicht gibt es von Seiten Shopware ja noch ein paar Tipps/Insights, wie das mit großen Katalogen insbesondere in Bezug auf Import/Indexierung praktisch sinnvoll zu handeln ist.

Jain… performant ja, aber der Preis wird nur angezeigt, wenn man den Cache auch löscht.

Ich mische mich einfach mal etwas ein. :wink:

Habe hier einen Shop mit 1,7 Mio Produkten - die Cross-Selling Tabelle hat 55,3 Mio Zuordnungen.
Einige Produkte haben > 25.000 Varianten.

Jetzt zum eigentlichen Thema: Ich nutze eine Kombination aus API und SQL.

Das Anlegen und Aktualisieren von Produkten mache ich über die API - das ist aber recht selten, geht aber noch recht schnell mit ca. 70 - 100 Produkten pro Sekunde. Aktualisieren ist für mich Eigenschaften / Optionen / Konfiguration / Bilder / Text. Natürlich über /_action/sync mit async-index.

Die Preise / Versandkosten etc. werden einmal pro Stunde aktualisiert - natürlich nur bei Änderungen - direkt per SQL.
Danach per API der Cache gelöscht, dass im Frontend der Preis korrekt angezeigt wird und der Kunde nicht im Warenkorb erst den richtigen Preis sieht.

Kurz zur Hardware…

Verstehe ich das richtig, dass alle Server-Dienste auf einem System laufen?
Habe ein ähnliches System und 128 GB funktionieren gut, aber 256 GB wären mir wirklich lieber…

Shopware 6 wird bei solchen Mengen an Daten einfach irgendwann langsam, Redis und ElasticSearch entlasten die MySQL-Datenbank sehr bzw. machen es überhaupt erst nutzbar.

Hast du die aktuelle Version? (Kenne das Problem, dass ein Update X Minuten braucht nur aus älteren Versionen.)
Wieviele Worker hast du bzw. nutzt du RabbitMQ?

Mit freundlichen Grüßen

1 „Gefällt mir“

@area-net-gmbh: In Shopware 5 haben wir es bisher so gehandhabt, dass wir unsere Artikel komplett upgedated haben. In Shopware 6 bin ich jetzt auch erstmal davon ausgegangen, weil wenn sich mal Änderungen ergeben, betrifft es oftmals auch mehrere Bereiche.
Darüber hinaus sind wir bei diversen Lieferanten mit Beständen und Preisen angebunden, Preise updaten wir in unserer Warenwirtschaft 1x täglich. Wenn sich hier Änderungen ergeben, übergeben wir diese über unsere Schnittstelle an alle relevanten Shops. Bei den Beständen wir sind wir tatsächlich schon dazu übergegangen, Updates direkt über die Datenbank auszuführen, weil auch die SW5 API hier an ihre Grenzen gestoßen ist und wir mehrfach täglich updaten müssen.

@sacrofano: Das könnten wir natürlich machen, aber Sinn der Sache sollte es ja eigentlich nicht sein. Vielleicht fehlt uns hier auch einfach die Erfahrung… Machen die „big player“ auch alles komplett in Eigenregie und abseits der vorgegebenen „Programmierpfade“ oder haben die größere und besser optimierte Server?

Gerade noch eine nette Entdeckung gemacht: php bin/console es:index --no-queue --env=PROD produziert im Webroot unter /var/log/ ein Log von 15GB. Der bekommt jetzt mal den Parameter --quiet dazu :slight_smile:

Wieso „–no-queue“? :scream:
Da läuft der Spaß doch nur in einem Prozess… klar, dass das Stunden dauert. :wink:

Moin @Teddie
Vielen Dank für deine ausführlichen Informationen, das gibt ja Hoffnung!

Unser Testsystem, auf das ich meine Aussagen beziehe, ist Shopware 6.5.6. Dein hybrider Ansatz klingt gut, fürs Anlegen die API und für Updates ggf. direkt über die Datenbank.
Tatsächlich verwenden wir (noch) kein RabbitMQ, da werden wir jetzt mal mit TimmeHosting in Kontakt treten, ob das für den Managed Server verfügbar ist.

Den es:index Befehl habe ich eben kopiert, der soll natürlich im Produktivsystem ohne --no-queue laufen. Wir bekommen unterschiedliche Ergebnisse (bzw Rückmeldungen) je nach Parameter (–no-queue Index ist knapp 500MB groß, ohne 160MB), daher testen wir hier gerade rum.

Alle Server-Dienste laufen auf der gleichen Maschine, dem besagten t9 Server bei Timme. Wir sprechen den gleichen Endpunkt an, Eigenschaften, Optionen oder Filter haben wir aktuell noch gar keine in der Testumgebung.

–no-queue ist größer, weil er selbst den Index erstellt und daher etwas Speicher braucht - ohne erstellt er „nur“ die Messages für die Worker.

Was bei mir gut läuft:

4 - 8 Worker für Async mit 2 GB
1 Worker für Sync mit 4 GB
1 Worker für Default mit 4GB
1 Worker für Fail mit 32 GB (Produktfeeds)

Im Idealfall ElasticSearch und Redis für den Cache auf einem separaten System, dann kannst du dem MySQL-Server auch 64 GB geben, bei mir hat er aktuell nur 32 GB, das ist „etwas“ zu wenig aber die SSD macht aber auch 4+ GB/s.
Noch die Logs einschränken… die belasten nur die SSD sinnlos.

Das geht natürlich alles nur auf, wenn du nicht noch Shopware 5 - Ballast rumschleppst. :wink:

2 „Gefällt mir“

@Teddie: Mal wieder vielen Dank :slight_smile: Leider sind wir/ich echt nicht firm in Sachen Hosting, solche Tipps sind Gold wert! Wir haben natürlich die Doku gewälzt und schon viel davon umgesetzt, aber dass RabbitMQ so ein großer Zugewinn sein kann, war uns bisher nicht klar.

Bei Timme müssten wir das problemlos einrichten können, es gibt auch Anleitungen dazu, das schauen wir uns gleich mal an.

Weiter oben hatte @raymond-de ja schon sehr praktische Tipps gegeben inklusive des Links zu den Performance Tweaks in der Doku.

Aus meiner persönlichen Erfahrung kann ich vielleicht noch einen recht hemdsärmeligen Tipp dazu packen. Wie Du selbst schon gesagt hattest, @area-net-gmbh, abhängig von der Datenart, die geupdated werden muss, kann man durchaus direkt ohne Framework- oder API-Zugriff auf die Datenbank gehen. Dazu legt man sich CSV-Dateien an einen bestimmten Ort und pumpt diese dann direkt per Cronjob auf dem Server (unter Umgehung eines Workers) in die Datenbank rein. So etwas habe ich - vor allem in solchen größeren Setups - schon mehrfach gesehen.

Selbst mir RabbitMQ kann man da in solche blöden Fallen laufen, dass das nächste Update schon wieder ansteht, wenn die Queue noch nicht abgearbeitet ist und dann baut sich das nach hinten raus auf.

Vielleicht noch etwas so neutral wie mir möglich zum Thema Shopsysteme: Ich denke, alle kämpfen da mit ähnlichen Effekten und solche Thematik bekommt man nicht von der Stange in Griff, das ist dann wirklich sehr projektbezogen. Ich kenne auch Shops mit mittlerweile > 20 Mio SKUs auf einem anderen System, aber dort ging es auch nur mit massivem Handanlegen. Letzten Endes hat man immer nur die Wahl, wo man den geringsten Aufwand hat :wink:

Ich weiß, dass solche Leute wie ScaleCommerce oder auch SysEleven (deren Hoodie ich grad trage) super gut für genau solche Szenarien aufgestellt sind aber das gibt’s natürlich nicht für 25 EUR im Monat. Eine andere Alternative wäre, dass ich Euch, @keszler, mal mit unserem (Shopware) Consulting-Team zusammenbringe.

Ich hänge mich auch mal dazu mit ein paar Tips:

  • queue Verarbeitung sollte auf jeden Fall mit einem KV store passieren (RabbitMQ oder mindestens REDIS). Die Standard Konfiguration läuft überhaupt nicht sauber mit mehreren Queue

  • REDIS alleine bringt schon viel

  • Bei häufigen großen Batches, macht auch ein Frontend Cache Sinn (Varnish)

  • Batches in der API entsprechend abbillden. Wir hatte uns dazu eine eigene API gebaut, die dann jeweils 10K Preise oder Stocks entgegennimt und dann direkt mit SQL in die DB einspielt. Final werden dann die entsprechenden Produkte als re-index und re-cache geschedult.

  • Search ohne ES ist eh ne Katastrophe.

  • Dazu kann man auch die DB und WebServer physikalisch trennen (oder in 2 Dockern fahren).

(Auch als Eigenwerbung mache ich gerne ein wenig technisches Coaching, einfach eine PM schicken)

LG

2 „Gefällt mir“

Wir haben jetzt erstmal Supervisor-Jobs für die Message Queue angelegt, ähnlich zu Teddies Konfiguration. Das scheint tatsächlich schon einen großen Boost zu bringen, wir testen es die Tage mal im Detail, aber es sieht schon vielversprechend aus!

@marco.steinhaeuser: Danke für deine Tipps! Auch ein interessanter Ansatz mit der CSV… wie ich hier überall heraushöre: Erlaubt ist, was geht.

Natürlich wissen wir auch, dass alle anderen Systeme mit ihren eigenen Problemen um die Ecke kommen werden. Deshalb wollen wir ja eigentlich auch gerne bei Shopware bleiben, da wir gute Erfahrungen gemacht haben und das Ökosystem schon ein wenig kennen. Die API war/ist allerdings eine große Umstellung und wie immer ist aller Anfang schwer… aber so langsam wird es, auch dank des echt tollen Feedbacks, das wir hier bekommen!
Dass wir natürlich auch entsprechendes Geld für entsprechende Leistung und know-how zahlen müssen, ist uns klar. 25€ zahlen wir auch jetzt schon nicht mehr, schön wärs :smiley: Daher sind auch solche Tipps mit bekannten high performance Hostern wertvoll für uns, beim Erstkontakt erzählt einem ja jeder, dass deren Hosting es packt. Wir würden gerne bei Timme bleiben, aber wenn es nicht geht, dann geht es nicht.
Das direkte Shopware-Consulting klingt auch sehr interessant. Die aktuellen Anpassungen aus den Tipps hier haben ja wie gesagt schon starke Verbesserung mit sich gebracht. Wir gehen jetzt mal die nächsten Schritte auf Seite unserer Schnittstelle und reichern weiter die Daten im Shop an, falls wir wieder auf Probleme stoßen, kommen wir gerne auf dich zurück!

@chamaw: Danke auch dir für die Tipps und das Angebot! Wie schon zu Marco gesagt: Falls wir nochmal auf Hürden stoßen, kommen wir auf einen direkten Austausch zurück!

Unsere alte API arbeitet übrigens sehr ähnlich, wie werden es wohl auch hier wieder darauf hinauslaufen lassen müssen, Updates über die Datenbank anstatt der API zu handhaben.
Redis und ES laufen, mehrere Worker zum Abarbeiten der Standard MQ jetzt wohl erstmal auch.

Es bleibt spannend, aber es ist schon mal gut und beruhigend zu wissen, dass definitiv noch Luft nach oben ist. Unsere Probleme hingen wohl einfach mit mangelnder Fachkenntnis bzgl. der Serverkonfiguration zusammen ¯_(ツ)_/¯ aber lieber so, als dass es gar nicht ginge, hätte uns eigentlich auch stark gewundert. Einige Branchengrößen verwenden ja Shopware, aber natürlich ist da auch etwas mehr Manpower und Geld hinter, als in unserem KMU.

3 „Gefällt mir“