Langsames Shop-Backend: Admin-Tempo für das Team steigern

Die Shopware-Verwaltung ist eine Anwendung, die im Browser läuft und jede Liste, jede Suche und jedes Speichern über die Admin-API vom Server holt. Diese Anfragen landen in der Regel beim selben PHP-Prozesspool wie die Seitenaufrufe Ihrer Kundschaft. Wie viele Anfragen dort gleichzeitig bedient werden, begrenzt die Einstellung pm.max_children (PHP-Handbuch). Sind alle Prozesse belegt, wartet die nächste Anfrage – egal, ob sie von einer Kundin im Checkout oder von einem Kollegen im Bestellmodul kommt.

Für die Bedienung gelten dieselben Wahrnehmungsgrenzen wie überall: Bis etwa 0,1 Sekunden (Nielsen Norman Group 1993) wirkt eine Reaktion unmittelbar. Bis etwa 1 Sekunde (Nielsen Norman Group 1993) bleibt der Gedankenfluss erhalten, auch wenn die Verzögerung auffällt. Ab etwa 10 Sekunden (Nielsen Norman Group 1993) wandert die Aufmerksamkeit ab, und Menschen beginnen nebenher etwas anderes. Für die Reaktion auf einen Klick gilt ein INP von 200 Millisekunden (web.dev) oder weniger als gut. Eine Bestellliste, die nach jedem Filterwechsel mehrere Sekunden braucht, liegt weit jenseits dessen, was sich flüssig anfühlt.

Im Alltag fällt das selten als Einzelereignis auf. Es zeigt sich als Summe: Die Liste lädt etwas länger, das Speichern zieht sich, die Suche reagiert erst spät auf die Eingabe. Wer am Tag viele Bestellungen anfasst, verliert diese Sekunden viele Male. Und weil die Verwaltung auf denselben Server zugreift wie der Shop, kann eine überlastete Verwaltung auch die Antwortzeit der Storefront verschlechtern.

Für Produktivsysteme empfiehlt die Dokumentation, die Warteschlange über die Kommandozeile abzuarbeiten. Dann werden Aufgaben auch erledigt, wenn niemand angemeldet ist, und die hohe CPU-Last durch mehrere Personen in der Verwaltung entfällt (Shopware-Dokumentation). Die Umstellung hat drei Teile: Worker als Dienst starten, den Admin-Worker abschalten und geplante Aufgaben getrennt anstoßen.

Die Worker selbst laufen als Dienst, den systemd oder Supervisor bei Bedarf neu startet. Die Dokumentation zeigt dafür eine systemd-Vorlage, aus der sich mehrere gleichartige Instanzen starten lassen, und eine Ziel-Unit, die sie gemeinsam startet. Jeder Worker beendet sich nach einer festen Laufzeit oder bei Erreichen einer Speichergrenze, im Beispiel der Dokumentation nach 60 Sekunden (Shopware-Dokumentation). Der Dienst startet ihn danach frisch. Das ist gewollt: Symfony rät, Worker nicht unbegrenzt laufen zu lassen, und nennt als Beispiel einen Neustart nach 10 Nachrichten (Symfony-Dokumentation), weil einzelne Dienste mit der Zeit Speicher ansammeln.

Wie viele Worker sinnvoll sind, hängt von der Art der Nachrichten ab. Produktindexierung läuft in der Regel langsam, andere Nachrichten sind schnell erledigt (Shopware-Dokumentation). Aus Erfahrung von Shopware sind bis zu drei Worker-Prozesse (Shopware-Dokumentation) im Produktivbetrieb normal und sinnvoll. Wer mehr braucht, verlagert die Warteschlange aus der Datenbank in ein eigenes Warteschlangensystem, damit die Datenbank nicht zum Engpass wird. Lange Indexierungsnachrichten lassen sich außerdem auf einen eigenen Transport legen, damit sie eilige Aufgaben wie den Mailversand nicht aufhalten.

Zwei Punkte gehören in den Ablauf jeder Auslieferung. Nach dem Einspielen neuen Codes beendet messenger:stop-workers die laufenden Worker sauber, damit sie mit dem neuen Stand neu starten (Symfony-Dokumentation). Und die Serverlast verschwindet durch die Umstellung nicht, sie wird planbar. Wie Sie den PHP-Prozesspool dafür passend bemessen, beschreibt der Beitrag zu OPcache, JIT und FPM-Workern.

Die Bestell- und die Produktliste gehören im Weihnachtsgeschäft zu den am häufigsten geöffneten Ansichten. Ihr Tempo hängt weniger an der Zahl der Zeilen auf dem Bildschirm als an der Abfrage dahinter. Jede Spalte, die Daten aus einer verknüpften Tabelle zeigt – Hersteller, Kundengruppe, Versandart, Zusatzfelder –, kann eine weitere Verknüpfung in der Abfrage bedeuten. Erweiterungen, die eigene Spalten oder Filter in Listen einhängen, vergrößern die Abfrage zusätzlich.

Teuer ist außerdem die Gesamtzahl. Eine Liste mit Seitenzahlen muss wissen, wie viele Treffer es insgesamt gibt. Die Admin-API kennt dafür mehrere Modi: keine Gesamtzahl, eine exakte Gesamtzahl oder nur die Auskunft, ob es eine weitere Seite gibt. Die exakte Zählung beschreibt die Dokumentation als rechenintensiv, die beiden anderen Modi als schnell (Shopware-Dokumentation). Für eigene Listen in Erweiterungen und für Schnittstellen, die nur durchblättern, reicht oft der Modus „gibt es eine nächste Seite“.

Wo eine Liste trotz schlanker Spalten langsam bleibt, kann die Ursache in der Datenbank selbst liegen: Filter auf Zusatzfelder, die in JSON-Spalten gespeichert sind, große Tabellen ohne Aufräumlauf, Sperren durch parallele Schreibvorgänge. Wie Sie solche Abfragen finden und beschleunigen, zeigt der Beitrag zur Optimierung von Datenbankabfragen.

Manche Arbeit lässt sich nicht vermeiden, aber verschieben. Ein vollständiger Neuaufbau aller Indizes erzeugt Nachrichten für sämtliche Datensätze – ausgelöst über die Kommandozeile oder über den entsprechenden Knopf in den Einstellungen der Verwaltung (Shopware-Dokumentation). Wer das an einem Vormittag im November anstößt, verlängert die Wartezeiten im Team, bis die Warteschlange leer ist. Für den ganzen Shop empfiehlt die Dokumentation dal:refresh:index mit der Option --use-queue, damit die Arbeit über die Warteschlange läuft; der passende Zeitpunkt dafür ist die Nacht.

Dazu kommen geplante Aufgaben. Ab Werk erzeugt Shopware die Sitemap einmal täglich, in der Liste der Standardaufgaben steht dafür ein Intervall von 86.400 Sekunden (Shopware-Dokumentation). Bei großen Katalogen kann diese Aufgabe die Warteschlange lange belegen und andere Aufgaben aufhalten. Seit Shopware 6.7.1.0 (Shopware-Dokumentation) lässt sich die geplante Sitemap-Erzeugung abschalten und per Cron zu einer ruhigen Uhrzeit starten. Die Aufgabe für Produktexporte steht in derselben Liste mit einem Intervall von 60 Sekunden (Shopware-Dokumentation) – wer viele Exporte pflegt, prüft deren eigene Intervalle.

Ein weiterer Kandidat ist der Indexer für dynamische Produktgruppen. Er pflegt eine Zuordnung von Produkten zu ihren Gruppen und kann bei großen Sortimenten oder häufigen Änderungen zum Engpass werden. Seit Shopware 6.6.10.0 (Shopware-Dokumentation) lässt er sich abschalten. Der Preis: Kategorieseiten mit dynamischen Produktgruppen zeigen eine Produktänderung erst, wenn der HTTP-Cache abläuft, und die Regelbedingung für Positionen in dynamischen Produktgruppen ergibt dann durchgehend „falsch“. Das ist eine Abwägung für Shops, die viel pflegen und wenig mit dynamischen Gruppen arbeiten, keine Standardeinstellung.

Welche der Stellen in Ihrem Shop bremst, zeigt nur eine Messung zur Arbeitszeit. Eine Messung am Sonntagabend mit einer einzigen angemeldeten Person findet weder den Admin-Worker noch die Sperren, die erst mit mehreren Workern auftreten. Sinnvoll ist ein Messfenster an einem normalen Arbeitstag, mit den Rollen, die tatsächlich arbeiten: Kundendienst, Versand, Artikelpflege.

Aus diesen Werten entsteht eine kleine Tabelle je Ansicht: Bestellliste, Produktliste, Suche, Speichern eines Artikels, Upload. Jede Zeile hat einen Ausgangswert vor der Umstellung und einen Wert danach, gemessen unter vergleichbarer Last. Wer vor dem Weihnachtsgeschäft zusätzlich wissen will, wie viel gleichzeitige Arbeit der Server trägt, ergänzt einen Lasttest, der Verwaltung und Shop zusammen belastet. Eine Performance-Analyse liefert dafür die Ausgangsmessung.