wollte mal eure Meinung zur Messenger Queue / RabbitMQ hören.
Wir setzen aktuell Shopware 6.4.4.1 ein mit folgendem Setup:
PHP 7.4 MYSQL 8.0 DB Dedizierter Root Server mit 128GB RAM / 20 Cores Appserver 1x Adminserver / 5x Webserver / 1x Worker (dort laufen nur Message Consume commands) RabbitMQ 3.8.16
Produktanzahl in Shops
25 - 50.000 Varianten
An Serverpower mangelt es mMn nicht wirklich und was Software angeht sind wir auch ziemlich up2date (lediglich PHP 8 wäre noch besser, vermuten aber auch das dies das Problem nicht lösen wird).
Aktuell haben wir relativ viele Lagerbewegungen und die Message Queue ist IMMER sehr voll (80.000 Messages in einem Shop). Problem ist, dass wir aktuell im Schnitt 0.5 Messages pro Sekunde verarbeiten, was mMn recht wenig ist, egal ob wir ein message:consume oder 20 laufen haben.
Meine Vermutung ist das hier Mysql stark abbremst, denn an PHP Power kann es nicht mangeln (habe schon versucht auf den 5 webservern über das starten von Consumern die TX/s zu erhöhen, aber ohne erfolg, geht von 0,4/s auf 0,5/s).
Ist das Problem bei Shops > 1000 Produkte bekannt? Hat hier jemand noch Tipps?
Manchmal habe ich das Gefühl das der Fokus hier kaum auf größere Setups gelegt wird. Ich bin seit ca. 5-6 Jahren ein überwiegend glücklicher Entwickler mit Shopware, aber so langsam bin ich wirklich am verzweifeln was das Thema Indexierung angeht. Ursprünglich war ich ja ein Fan davon, zmd. in der Theorie, da es für extreme Lasten perfekt ist. Das merken wir auch bei einem Shop mit 400 Produkten bei dem 1000 Bestelleingänge in 5 Minuten kein Problem sind (und unser Zahlungsanbieter das Bottleneck war). Aber wenn Produkte einfach nicht up2date im Shop sind und man immer wieder die Message queue purgen muss um dann einen dal:refresh:index laufen zu lassen (da die queue wegen der langsamen Verarbeitung das Produkt vermutlich 4 mal enthält), hinterfrage ich aktuell wirklich die weitere Nutzung und schau mich von Zeit zu Zeit nach Alternativen um.
90% der umgesetzten Features sind übrigens sehr nice! Aber wenn sowas wie Bestandsanzeige von Haus aus nicht sauber funktioniert ist das schon doof und Shopware 6 ist nun schon seit fast 2 Jahren Live.
Hallo, wir haben ca. die gleiche Konstellation und genau das gleiche Problem.
Gab es hierfür eine Lösung?
Wir haben PHP 8.2, MySql 8 und Shopware Version 6.5.8.6 im Einsatz.
Wenn wir die API mit Artikelupdates befeuern steigt die Warteschlange immer innerhalb kürzester Zeit an bis zum Ende und arbeitet dann 1 Message pro Sekunde ab.
Der Message-Queue ist m.M.n. nicht wirklich geeignet, um relevante Artikeldaten in großen Mengen zu aktualisieren.
Aktuell läuft es bei uns ganz gut mit folgendem Ablauf:
WaWi-Export in eigene DB-Tabellen
Aus diesen Tabellen wird dann über direktes Sql alle Bestände & Preise jeweils in einem Query aktualisiert. Die Daten ändern sich recht schnell mal, deswegen müssen die auch schnell verarbeitet werden und da können wir nicht auf den Message-Queue warten. Das sind insgesamt 4 Queries um alle Bestände, VKs, EKs, UVPs innerhalb von ein paar Sekunden zu aktualisieren.
Andere nicht so relevante Artikeldaten, wie Beschreibungen, Eigenschaften etc. werden dann über den Message-Queue abgearbeitet. Diese Daten ändern sich in der Regel nicht oft, deswegen ist der eigentlich immer recht clean.
Wir haben sehr viele Bestandsänderungen, wenn wir diese über eine Query direkt in der DB ändern, benötigt es den Cache zu leeren. Preisänderungen finde ich auch über die DB zu machen ganz OK.
Aber wir müssen zur Zeit die kompletten Produkte einmal durchupdaten, vor allem wegen allen Bildern sprich den API Endpunkt Media To Produkt, dass sind dann gleich mal einige 100000 Aufrufe, wie soll man dann dies lösen.
API–Calls von außen im Batch-Modus um http-Request zu minimieren. Die Abarbeitung der einzelnen Updates wird dadurch aber nicht schneller.
Wenn ein CDN für die Bilder/Medien eingesetzt wird oder die Bildquelle von extern kommt, dann auf jeden Fall nicht über den Message-Queue abarbeiten. Upload/Download nimmt relativ viel Zeit in Anspruch und „verstopft“ den Message-Queue.
Ich mache jetzt gar nichts mehr über den Message-Queue.
Alle Update-Prozesse werden separiert (Preise, Bestände, Kategorien, Bilder, Artikelneuanlage etc.).
Update–Plugin indem jeder Prozess ein eigener Command ist (bin/console artikelupdate:preise:vk)
Wenn möglich über direktes Sql aktualisieren, ansonsten Update über Repositories.
Alles dann als einzelne Cronjobs angelegt, die flexibel getimed sind. Bilder-Update und Artikelneuanlage z.B. immer nur Nachts um die Last zu verteilen. Muss man dann herumprobieren, wie es am besten für einen passt.
Insgesamt habe ich so mehr Kontrolle über die Artikelupdates und bin flexibler.