Was Shopware im Hintergrund neu berechnet

Es gibt eine Sorte Fehlermeldung, die keine ist: Jemand pflegt einen Wert, speichert, ruft die Seite auf — und sieht den alten Stand. Kein Fehler, kein Hinweis, nichts im Log. In den meisten dieser Fälle ist der Wert längst gespeichert. Was fehlt, ist die Neuberechnung dessen, was daraus abgeleitet wird.

Dafür gibt es in Shopware eine eigene Schicht. Wir haben sie ausgelesen.

Wie viele Indexer es tatsächlich gibt

Über die EntityIndexerRegistry der beiden laufenden Kernel gezählt, getrennt nach Herkunft:

Der Unterschied ist genau einer, und er ist aufschlussreich: In 6.7 kommt product.description_teaser.indexer hinzu.

Der neue Indexer und das schreibgeschützte Feld

Das Feld description_teaser ist in 6.7 WriteProtected. Ein Schreibzugriff von außen — über die Admin-API, über ein Importwerkzeug, über ein Übersetzungs-Plugin — wird abgewiesen. Gleichzeitig gibt es jetzt einen Indexer, der genau dieses Feld befüllt: Der Kern berechnet den Teaser selbst aus der Beschreibung.

Für Betreiber bedeutet das zweierlei. Erstens: Wer den Teaser bisher über eine Schnittstelle gepflegt hat, bekommt in 6.7 einen Fehler statt eines Werts. Zweitens: Wer ihn gar nicht gepflegt hat, bekommt plötzlich einen — abgeleitet aus der Beschreibung, ohne dass jemand darum gebeten hätte.

Wer den Versionswechsel plant, findet die übrigen Unterschiede in unserer Gegenüberstellung 6.7 wechseln oder bei 6.6 bleiben.

Was die wichtigsten Indexer tun

Die Namen sind selbsterklärend, ihre Wirkung nicht immer:

Die Suche ist der Fall, der am häufigsten auffällt — und der, bei dem am häufigsten am falschen Ende gesucht wird. Wir haben gemessen, warum die Shopware-Suche Produkte nicht findet; der Indexlauf ist einer der Gründe, aber nicht der einzige.

Drei Betriebsarten, drei Verhaltensweisen

Der entscheidende Punkt für den Betrieb ist nicht, welche Indexer es gibt, sondern wann sie laufen:

Sofort. Im einfachsten Fall läuft der Indexer direkt beim Speichern. Der Vorgang dauert dadurch länger, aber das Ergebnis ist unmittelbar da. Für kleine Kataloge ist das der unauffälligste Modus.

Über die Warteschlange. Der Standard im produktiven Betrieb: Die Aufgabe wird in die Warteschlange gelegt und von einem Worker abgearbeitet. Das Speichern bleibt schnell. Läuft kein Worker, passiert allerdings nichts — und genau das ist die häufigste Ursache für „die Änderung kommt nicht an".

Ausgeschaltet. Einzelne Indexer lassen sich für Massenimporte gezielt abschalten und danach einmal vollständig laufen lassen. Das ist sinnvoll, wenn 50.000 Produkte auf einmal kommen — und gefährlich, wenn jemand vergisst, sie wieder einzuschalten.

Zur Unterscheidung: Indexer sind nicht dasselbe wie geplante Aufgaben. Was Shopware an wiederkehrender Arbeit erledigt — Aufräumen, Sitemap, Newsletter, Löschfristen —, haben wir in Was Shopware im Hintergrund erledigt beschrieben. Indexer reagieren auf Änderungen, Tasks laufen nach Zeitplan.

Die Diagnose bei „Änderung kommt nicht an"

1. Steht der Wert in der Datenbank? In der Verwaltung noch einmal öffnen. Steht er da, ist das Speichern nicht das Problem.
2. Läuft ein Worker? Ohne laufenden Worker bleibt im Warteschlangenbetrieb jede Aufgabe liegen. Das betrifft Indexer, E-Mails und geplante Aufgaben gleichzeitig — wenn mehrere Dinge auf einmal „nicht funktionieren", ist das fast immer die Ursache.
3. Ist der Indexer abgeschaltet? Nach Importen oder Migrationen bleibt das gern stehen.
4. Einmal gezielt neu bauen. Für einzelne Bereiche genügt ein Lauf des zuständigen Indexers; ein vollständiger Neuaufbau ist bei großen Katalogen teuer und selten nötig.

Grenzen dieser Messung

Gezählt haben wir die registrierten Indexer zweier laufender Installationen, nicht ihre Laufzeiten und nicht ihre Last. Die Zahlen gelten für den Kern plus die dort installierten Erweiterungen; ein Shop mit anderen Plugins hat andere. Wie lange ein vollständiger Neuaufbau bei welcher Katalogröße dauert, ist eine eigene Frage und hier nicht beantwortet.