Mit dem Index habe ich noch meine Probleme, mal ist der total schnell, mal dauert es ewig.
Kann man eigentlich statt die Messages abzuarbeiten auch am Anschluss aller Änderung den Index neustarten mit „bin/console dal:refresh:index“, hätte das den selben Effekt?
Wenn ja könnte man die Tabelle „enqueue“ ja dann leeren, oder?
Der Befehl baut den Index direkt synchron auf, mit den Parameter „–use-queue“ wird das in die Message Queue verlagert und asynchron abgebaut.
Je nach Menge an Daten dauert die direkte Verarbeitung aber unterschiedlich lange und benötigt auch entsprechend Ressourcen.
Generell aber sollte man sich die Frage stellen wann ein vollständiger Neuaufbau nötig ist. Im Normalfall baut Shopware den Index inkrementell auf sobald Änderungen stattfinden.
Ok das habe ich jetzt soweit verstanden, danke.
Wir wollen bei uns eine Mischung machen aus Produkt anlage/Update über die Api und einen Import direkt über die Datenbank, weil der Chef jede Nacht alle Preise geupdatet haben will und das bei 50.000 Artikel zeitlich ein Problem ist.
Nachdem Update über die Datenbank soll dann der reeindex laufen wobei ich aus diesem dann auch einige Sachen über Skipp ausschließe wie z.B. media.index.
Dieser reindex ist in den ersten Tests auch jeweils in paar minuten durchgelaufen, nur heute hat er ewig gebraucht, was ich bisher noch nicht verstanden habe wo der unterschied war.
Den Update über die Datenbank wird Shopware denke nicht mitbekommen, weshalb hier ein inkrementeller Aufbau nicht stattfinden wird, oder habe ich einen Denkfehler?
Direkte Änderungen an der Datenbank (was übrigens nicht generell empfehlenswert ist) werden natürlich vom System nicht erfasst. Es sollte da lieber die API genutzt werden, da gibt es auch die Möglichkeit zu sagen ob es direkt in den Index soll oder nicht:
LG Andre
Die ganze Indexierung Geschichte läuft noch nicht so, dass SW6 für Kunden mit vielen Artikeln geeignet ist.
Hier einmal zum Thema:
Wenn das Abarbeiten für die Indexierung so viele Ressourcen benötigt, dass es nahezu unmöglich wird einen Shop mit vielen Artikeln zu betreiben, ist es fraglich ob Shopware das hier zu Ernst genommen hat:
Ich finde auch, dass das eine Stärke und Schwäche zugleich ist.
Das iterative ist perfekt für normale Änderungen im Backen. Gerade aber beim Abgleich großer Datenmengen sollte es die Möglichkeit geben, die Indexierung für den Vorgang auszuschalten und im Nachhinein dann die Daten indexieren zu lassen.
Wobei, wenn der EventDispatcher keine 2 MB blocken würde pro Iteration, dann wären alle Vorgänge wohl wesentlich schneller.
Selbst mit der Möglichkeit die Indexierung zu deaktivieren und nur einmal zu indexieren würde sich das System bei Artikeln mit vielen Varianten aufhängen und zwar beim searchKeywordUpdater.
Ich habe das hier getestet:
Ohne den searchKeywordUpdater benötigt das Indexing 300MB RAM und mit reichen keine 10GB aus.
Verlagert man den Prozess ins asynchrone dauert der Task viel zu lange - für einen größeren Shop mit regelmäßigem Datenabgleich ist SW6 aktuell fehlerhaft.
Gibt es dazu denn ein Ticket auf issues.shopware.com?
Wenn du speziell das Thema mit den Varianten analyisiert hast, macht es ja Sinn dies auch zu melden. Schick das gerne mal hier ind en Thread.
es gibt sehr viele Tickets, die denke ich damit zusammenhängen - ich habe mich jetzt nur einmal in den letzten 16 Stunden intensiv damit beschäftigt und debugged, da wir bereits 2 Serverumzüge für den Import von 5000 Produkten hinter uns haben und es mit 16GB immer noch nicht funktioniert. Das ist wirklich ganz bitter, da wir noch vier B2B-Projekte am laufen haben - muss jetzt den Kunden sagen, dass sie einen Server mit 100GB+ RAM benötigen, um ihren Lagerbestand zu synchroniseren.
Shopware Issuetracker → hier geht es auch um den searchKeywordUpdater, ob das Auswirkungen auf die Performance hat weiß ich nicht
Shopware Issuetracker
Ich bin der OP des Themas hier mit anderem Account.
Ja das ganze Thema ist echt traurig, wir sind mittlerweile von Shopware weg für die großen Systeme - es war die beste Entscheidung auch wenn ich Shopware sehr mag und auch Symfony Entwickler bin. Es war kein Vorankommen dort mit Stocks bis 10Mio Produkten einfach unglaublich nervig.
2 Monate später bin ich froh das wir weg sind, so leid es mir tut! Ich sage bewusst nicht wohin ABER dort flutscht es mit Elastic und Indexierung einfach Sahne 
@thomas.baier.halle
Du hattest das Thema ja bereits im Januar 2021 angesprochen und es scheint so, als ob Shopware keinen Demo-Entwicklungsshop mit vielen Varianten nutzt - ansonsten hätte das mit dem repository-update/insert/delete schon längst auffallen müssen. Ich wundere mich allerdings schon, dass sich bisher so wenige zu dem Thema gemeldet haben, da das wirklich ein gravierender Negativpunkt ist.
Da kommt selbst WooCommerce mit mehr Varianten klar 
Wie gesagt bin ich immer noch ein großer Fan von SW6 allerdings muss das mit der Indexierung ASAP in den Griff bekommen werden - ansonsten können nur kleinere Kunden mit sehr wenig Varianten das Shopsystem nutzen.
Also wie am Anfang erwähnt arbeiteten wir nicht mit Varianten. Wir hatten ca. 20 Custom Fields für die ~10Mio Produkte. Das war es aber auch, keine speziellen preisregeln, e.t.c… Einfach 10Mio Produkte mit 20 Custom Fields in ~40 Kategorien und ca ~11 Sales Channel. Also im Prinzip nix aufwendig konfiguriertes. Es ist halt die Masse an Produkten und SEO Url’s scheinbar. Kein Plan! Auch die DeadMessages haben wir per Decorator gekillt und und und…bin froh das dieser Kunde weg ist.
Das sich so wenige melden liegt sicher daran das nicht jeder einen größeren Stock hat. Ich denke Shops laufen mit ein paar hundert oder ein paar tausend Produkten. Viele Produkte heißt ja nicht viel mehr Umsatz unbedingt also auch große Player mit Shopware sind davon eventuell so nicht betroffen.
Mit 6.4 wurde ja ein verbessertes Indexing versprochen. Wir hatten damals ein staging aufgezogen, es fürhte aber von Wechsel 6.3 auf 6.4 kein Weg an einer neu-indexierung vorbei. Wir haben lange probiert es ohne zum laufen zu kriegen und dann alles abgebrochen und System geswitcht. Die erste Indexierung lief Monate, was weiß ich wie lange eine neue Indexierung unter 6.4 gelaufen wäre. Wir haben es zwar auch probiert aber ohne deutlichen Vorteil auch wenn einige schneller ging unter 6.4. Wir waren also auf 6.3.5 festgenagelt ohne Chance auf Update ohne neu-Indexierung.
@Moritz_Naczenski
Wenn es am searchKeywordUpdater liegen sollte, ein Produkt mehrere Varianten hat - Werden dann alle Varianten des Hauptprodukts neu indexiert?
$this->searchKeywordUpdater->update(array_merge($ids, **$childrenIds**), $context);
Das scheint mir aktuell so zu sein, was die Performanceeinbußen natürlich erklären würde.
Also ich aktualisiere das Hauptprodukt und dann werden durch den searchKeyWordUpdater alle Varianten hergeholt und aktualisiert!?!?
Zum Einen sollte geprüft werden, was beim repository->update/insert usw. getan wird → also wenn ich lediglich Dinge aktualisiere, die den Stock betreffen, sollte Shopware hier nicht auch die searchKeywords neu aufbauen. Zum anderen sollte bei einem Hauptprodukt-Update nicht alle Varianten des dazugehörigen Hauptprodukts beim searchKeyWordUpdater neu indexiert werden.
Wir planen aktuell auch einen Wechsel zu Shopware 6. Dazu haben wir parallel zu unserem Hauptshop einen weiteren Shop aufgesetzt indem wir bereits ca 120 Tausend Artikel haben. Ein Wechsel mit unseren haupt Sortiment ist aber aktuell noch nicht denkbar, insbesodnere aufgrund der Performance Probleme.
Gerade läuft z.B. der Indexer im Backend und meldet:
Kategorie-Indexierung: Circa 2026650 Kategorien verbleiben
Wir haben nicht annähernd so viele Kategorien (ungefähr ein paar hundert). Weshalb diese Zahl schon verwundert.
Auch andere Dinge machen Probleme. Zum Beispiel dauert das Aufräumen/ Löschen der Cache nach einem Update mehrere Stunden. Das führt dann zu einer langen Down Zeit. Auch das regelmäßige aktualisieren des Bestandes über die API ist kaum möglich, da dies zu lange dauert. Ein ändern des Bestands direkt über die Datenbank wird hingegen nicht zuverlässig übernommen.
In unserem anderen Shop mit ca 40k Artikeln und einem anderen Shopsystem haben wir solche Probleme nicht.
Der Shop hat aktuell nicht mal eine Handvoll Varianten Artikel. Ist da Besserung zu erwarten oder ist Shopware wirklich so ungeeignet für große Produktmengen?
Wenn du keine schlaflosen Nächte haben willst kann ich dir nur raten: Finger weg!!!
Da ich, mal abgesehen von einigen vermeidbaren Bugs, SW6 ganz gut finde, aber nicht auf Änderungen seitens SW warten wollte, habe ich das über ein eigenes (performance optimiertes) Plugin gelöst. Bei ca. 15.000 Artikeln incl. Varianten braucht der Server nur noch ca. 70MB RAM und ca 65 Sekunden. Positiver Nebeneffekt ist, dass die Tabelle „product_search_keyword“ und die zugehörigen Indizes kleiner geworden sind und die Suche im Frontend auch die Sachen findet, die erwartet werden. Allerdings habe ich an den „kritischen Stellen“ auf SW-Logik verzichtet. Bei Bedarf kann ich gern Tips zum „Nachbauen“ geben
Richtig cool wäre ja ein gemeinsames Projekt dazu, z.B. auf Github
kannst Du ja gern initiieren , leiste gern meinen Beitrag
Kann man doch gut als Plugin im Store anbieten. Habe auch Kunden, die Shopware 6 nicht nutzen können - wegen Varianten z.B. - Shopwares Empfehlung: Nutzt doch Custom Products 
Ansonsten verkaufs einfach inoffiziell.
könnte ich sicher machen, aber den ganzen Stress mit den Haftungsfragen und dem Support der ggf erwartet wird, den will ich nicht haben. Deshalb zeige ich gern meinen Weg und gebe auch Code-Snipptes weiter.