Welche Auswirkungen haben die verschiedenen Indexing Optionen der SyncAPI ?

Shopware 6 (German) Programmierung
1

Hallo zusammen,

habe eine kurze Frage zum Indexing da ich gerade mit den verschiedenen Header Optionen der SyncAPI experimentiere.
Ich benutze nur die API, habe aber relativ wenig know-how über Templates und was da bei einem Shop im Hintergrund alles passiert.

Wenn ich das Indexing z.B. deaktivere oder verlagere über die verschiedenen „indexing-behavior“ dann werden z.B. neue Kategorien ja erst etwas verzögert oder überhaupt nicht im Frontend/Backend angezeigt bis eben die Indexierung im Hintergrund durch ist oder ich bzw. der Nutzer manuell über den Adminbereich die Indexierung anstößt.
Das ist so weit alles klar da ich wie gesagt aber nicht viel Ahnung von den Hintergrundprozessen habe ist meine Frage, ob es noch andere Auswirkungen hat?

Da ich am überlegen bin dauerhaft auf „use-queue-indexing“ zu setzen oder zumindest dem Nutzer die Option zu bieten wollte ich eben auch Nummer sicher gehen, nicht das am Ende irgendwelche Probleme auftreten, die mir vorher so nicht klar waren.

//EDIT:
Nochmal kurz eine Ergänzung bzw. eine weitere Frage.
Ich habe gerade Tests mit dem Aktualisieren der Produktpreise gemacht, keine Regeln, einfach nur der Preis direkt am Artikel.
Da scheint es so, dass das Indexing überhaupt keine Auswirkung hat also auch mit disable-indexing wird der Preis zum Artikel, im Backend, der Suche, der Kategorie und direkt beim Artikel immer sofort angezeigt.
Es ist aber wohl so, dass trotz allem bei einem direkten Update des Preises per PATCH auf das Produkt ein Indexing stattfindet, denn der Request braucht etwas die doppelte Zeit bei nur einem Preis im Vergleich zur SyncAPI mit einem Preis und disable-indexing.
Daher nochmal die Frage, ob es irgendwelche anderen Auswirkungen hat oder könnte man für sowas an der Stelle ohne Probleme aus Performancegründen auf die SyncAPI ohne Indexing setzen?

Vielen Dank für eure Zeit.

Beste Grüße
Simon

2

Hallo,

also grundsätzlich denke ich hast du die Erklärung der indexing-header bestimmt gelesen:
Shopware 6: Sync api

Jetzt mal zu meiner Erfahrung:

Es kommt eben drauf an um wie viele Produkte es sich handelt!
Prinzipiell verschiebst du die performance Probleme nur.

Folgende 2 Header beschleunigen den IMPORT massiv:

--header 'indexing-behavior: use-queue-indexing'
--header 'indexing-behavior: disable-indexing'

Die Daten werden in beiden Fällen in die MySQL DB geschrieben, in beiden fällen muss aber noch Indexiert werden.

Mit ‚use-queue-indexing‘ nutz man die „message queue“ und es werden events in die Tabelle „enqueue“ geschrieben welche dann durch entweder:

a) Den Admin-Worker abgearbeitet werden

ODER
b) Den CLI-Worker, sofern du den Admin-Worker deaktiviert hast und das per CLI regelst

Schau dir hierzu die worker settings mal an:
Shopware 6: Message Queue

Mit ‚disable-indexing‘ musst du halt das indexieren per Hand ausführen über:

a) Die CLI

ODER
b) bei aktiviertem Admin-Worker über den button im Backend

So nun zu meinem eingehendem Statement „Es kommt eben drauf an um wie viele Produkte es sich handelt!“:

Bei kleineren Mengen (ein paar hundert Produkte) würde ich den Header weglassen und sofort indexieren.
Bei meinem aktuellen Beispiel geht es um ca. 10Mio Produkte die ich mit ‚use-queue-indexing‘ importiert habe.
Der Import ging super flott, das Indexieren rattert nun ewig und wird noch 2-3 Monate rattern!

Hierzu gibt es auch einen Hilferuf von mir, bisher leider ohne Erfolg:
https://forum.shopware.com/discussion/74533/performance-optimierung-indexierung

Beim Indexieren werden u.a die SEO URL’s generiert (vorher sind die Artikel mit einer vorl. URL erreichbar) und so weiter.
Bei Einsatz von Elastic-Search ist zu beachten das die Artikel weder im Frontend noch im Backend auftauchen before sie indexiert sind!

Also kurzum: Du verlagerst die Performance-Problemchen nur und je nach Artikel-Anzahl würde ich gleich Indexieren.

Grüße!

1 „Gefällt mir“
3

Wenn man beide Header verwendet:

--header 'indexing-behavior: use-queue-indexing'
--header 'indexing-behavior: disable-indexing'

Gilt dann nicht nur der zweite, da dieser den ersten überschreibt oder werden beide als Flags übernommen?

4

Richtig, ich habe die Header nur aufgelistet um zu zeigen welche der Header etwas an Performance machen (nur Verschiebung des Problems). Natürlich sollte man nur 1 Option wählen.

1 „Gefällt mir“
5

Verwendet man also den Header use-queue-indexing, so startet er eine gesamte Neuindexierung und nicht bloß eine spezifisch, die sich um die gesendeten Produkte (oder andere Objekte) dreht, richtig?

Das würde bedeuten, dass es das Beste wäre, am Ende eines Exports noch ein leeres Indexing-Paket zu senden.

6

Nein! use-queue-indexing bedeutet einfach das nicht direkt indexiert wird sondern eben in die Warteschlange ausgelagert wird (Die dann mit einem Worker abgearbeitet wird)

Es werden also pro update oder create ein Job angelegt der dann abgearbeitet wird und die Indexierung beginnt. Die Indexierungsjobs beinhalten DB-Arbeiten als auch natürlich Elastic-Arbeiten. Es wird nicht alles neu indexiert. Der header bedeutet nur: „Nimm die Daten an, verlagere die Hauptarbeit aber in den Worker“

1 „Gefällt mir“
7

Hallo,
das Update für Produkte und Preise per API dauert extrem lange. Deshalb habe ich die unterschiedlichen ‚indexing-behavior‘ ausprobiert. ‚use-queue-indexing‘ ist dabei nur unwesentlich schneller. ‚disable-indexing‘ ist allerdings ca. 200 mal schneller.
Ich habe das beim Preisupdate getestet. Dabei ist mir aufgefallen, dass die Preise auf der Website sofort wie im API update waren. Muss dafür wirklich dann noch ein Indexer ausgeführt werden? Wenn ja, ist das der „product.indexer“ in Einstellungen unter caches&indexes.