Shopware 6.7 Performance: erst die langsame Ebene finden

Schritt 0: Baseline aufnehmen

Wählen Sie drei URLs, die ein nicht eingeloggter Besucher öffnen kann: die Startseite, eine Kategorieseite und eine Produktseite. Rufen Sie jede zweimal auf und notieren Sie die Zeit bis zum ersten Byte (TTFB), also die Zeit, bis der Server beginnt, die Seite zu senden.

for url in \
  https://shop.example.com/ \
  https://shop.example.com/category-name/ \
  https://shop.example.com/product-name/SW10001; do
  for run in 1 2; do
    curl -s -o /dev/null -w "run $run  ttfb %{time_starttransfer}s  %{http_code}  $url\n" "$url"
  done
done

curl sendet keine Cookies, deshalb sieht Shopware einen Besucher, der nicht eingeloggt ist und einen leeren Warenkorb hat. Genau diesen Traffic bedient der HTTP-Cache. Shopware setzt ein Cookie sw-states mit den Zuständen logged-in und cart-filled, und eine Anfrage mit einem der beiden Zustände überspringt den Cache.

Die zwei Durchläufe lesen

• Lauf 1 langsam, Lauf 2 schnell: Der Cache funktioniert. Lauf 1 zeigt, was jeder Cache-Miss kostet. Weiter mit Schritt 3.
• Beide Läufe langsam und etwa gleich: Die Seiten kommen nicht aus einem Cache. Weiter mit Schritt 1.
• Beide Läufe schnell: Nicht eingeloggte Besucher sind serverseitig in Ordnung. Prüfen Sie die Queue (Schritt 2), dann eingeloggte Besucher und Besucher mit gefülltem Warenkorb (Schritt 3), dann das Frontend (Schritt 5).

Vergleichen Sie die beiden Läufe miteinander und achten Sie auf den Abstand. Die absoluten Werte hängen von Ihrem Hosting ab; behalten Sie sie als eigene Referenz und führen Sie dieselbe Schleife nach jeder Änderung aus. Betreiben Sie mehrere App-Server hinter einem Load Balancer mit Datei-Cache, kann Lauf 2 auf einem Server landen, der die Seite noch nicht gecacht hat. Wiederholen Sie die Anfrage dann ein paar Mal.

Schritt 1: Ist der HTTP-Cache an und werden Seiten daraus bedient?

Zwei gleich langsame Läufe bedeuten, dass die Seite bei jeder Anfrage neu gebaut wird. Der HTTP-Cache von Shopware ist in 6.7 standardmäßig aktiv (SHOPWARE_HTTP_CACHE_ENABLED steht auf 1). Suchen Sie deshalb nach den üblichen Gründen, warum er nicht greift:

• Er ist ausgeschaltet: Eine Umgebung setzt SHOPWARE_HTTP_CACHE_ENABLED=0. Prüfen Sie die .env-Dateien und die Umgebungsvariablen des Servers.
• Etwas vor Shopware umgeht ihn: Ein CDN oder Proxy, der kein HTML cacht, oder eine Regel, die die Cache-Header entfernt. Lesen Sie auch den Treffer-Header dieser Ebene (Cloudflare sendet cf-cache-status).
• Der Test-Client wirkt eingeloggt: Ein Cookie-Speicher aus einer Sitzung mit gefülltem Warenkorb sendet den Zustand cart-filled und bekommt nie eine gecachte Seite.

Sind die Seiten gecacht, entscheiden zwei Dinge, wie gut der Cache unter Last hält: wo er liegt und wie Invalidierungen behandelt werden. Die Cache-Gruppe der Checkliste deckt beides ab. App- und System-Cache nach Redis verschieben ist wichtig, weil der Datei-Cache unter Last langsamer wird und sich nicht zwischen App-Servern teilen lässt. Ausstehende Cache-Invalidierungen in Redis halten ist wichtig, weil sie standardmäßig in einer MySQL-Tabelle warten, die bei einem stark beschriebenen Shop in einen Deadlock laufen kann. Das Download-Formular der Checkliste finden Sie weiter unten auf dieser Seite.

Schritt 2: Kommt die Queue hinterher?

Verspätete Bestellmails, stockende Importe, eine Indexierung, die den Produktänderungen hinterherhinkt, und Admin-Aktionen, die scheinbar nichts tun, sind Queue-Symptome. Ein Befehl zeigt den Rückstand:

bin/console messenger:stats

Er gibt pro Transport die Anzahl wartender Nachrichten aus. Er funktioniert für Transports, die ihre Nachrichten zählen können, und sowohl der Doctrine-Transport (der Standard) als auch der Redis-Transport können das. Führen Sie ihn mehrmals über einige Minuten aus:

• Die Zahlen wachsen weiter: Die Worker kommen mit der Last nicht hinterher.
• Eine Zahl über null, die sich nie bewegt: Niemand verarbeitet diesen Transport.
• Die Zahlen gehen auf null zurück: Die Queue ist gesund, diese Ebene ist nicht Ihr Problem.

Eine häufige Ursache für eine Queue, die niemand abarbeitet, ist der Admin-Worker: Er verarbeitet die Queue nur, solange jemand die Administration geöffnet hat. Der Checklisten-Punkt Admin-Worker abschalten und echte Worker betreiben erklärt die Lösung, und die Gruppe Queue und Cron deckt Scheduled Tasks, Mails und die Sitemap ab. Um die Queue ganz von MySQL zu nehmen, folgen Sie der Redis-Streams-Anleitung.

Schritt 3: Wo verbringen PHP und die Datenbank ihre Zeit?

Lauf 1 aus der Baseline und jede Anfrage eines eingeloggten Besuchers oder eines Besuchers mit gefülltem Warenkorb zahlen die vollen Kosten für den Seitenaufbau. Zwei Sichten zeigen, wohin diese Zeit geht.

Server-Timing: Backend-Schritte im Browser

Shopware liefert eine Profiler-Integration namens ServerTiming mit. Aktivieren Sie sie, und jede Antwort enthält einen Server-Timing-Header, der die erfassten Schritte mit ihrer Dauer in Millisekunden auflistet.

# config/packages/shopware.yaml
shopware:
    profiler:
        integrations:
            - ServerTiming

Laden Sie eine langsame Seite neu, öffnen Sie in den Entwicklertools Ihres Browsers das Netzwerk-Panel und sehen Sie sich den Tab Timing der Dokumentanfrage an. curl -sI zeigt denselben Header im Terminal.

Das Slow Query Log: Wofür MySQL seine Zeit braucht

Schalten Sie das Slow Query Log von MySQL eine Weile ein und lassen Sie echten Traffic es füllen:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Das protokolliert jede Abfrage, die länger als eine Sekunde dauert. SHOW VARIABLES LIKE 'slow_query_log_file' gibt den Pfad der Logdatei aus, und mysqldumpslow gruppiert ähnliche Abfragen. Setzen Sie slow_query_log wieder auf 'OFF', wenn Sie fertig sind, denn das Log wächst mit dem Traffic. MariaDB verwendet dieselben Variablen.

Für einen Aufrufbaum statt einer Schrittliste nutzen Sie einen Profiler. Shopware liefert außerdem Integrationen für Tideways und Datadog mit, die in derselben Liste shopware.profiler.integrations aktiviert werden.

Wissen Sie, welche Schritte dominieren, nimmt die Checkliste ihnen Arbeit ab. Ihre Gruppe PHP und Deployment (OPcache, die kompilierte Umgebungsdatei, die Composer-Classmap) senkt den Overhead pro Anfrage. Ihre Gruppe Katalog und Storefront (reduzierte Produktdaten in Listings, der Product-Stream-Indexer) senkt die Arbeit pro Seite und pro Produktspeicherung.

Schritt 4: Läuft die Suche wirklich auf OpenSearch?

Langsame Listings, langsame Filter und langsame Suchergebnisse können bedeuten, dass die Suche gegen MySQL läuft. Wenn OpenSearch oder Elasticsearch ausfällt, führt Shopware die Suche stillschweigend gegen MySQL aus, und bei einem großen Katalog kann dieser Fallback die Datenbank überlasten. Betreiben Sie gar kein OpenSearch, springen Sie zu Schritt 5.

bin/console es:status

es:status meldet den Zustand des Clusters und ob die Indexierung aktuell ist. Ein Cluster, der nicht grün ist, oder ein Befehl, der sich nicht verbinden kann, ist Ihre Antwort. Die Elasticsearch/OpenSearch-Anleitung behandelt die Einstellung, die den stillen Fallback in einen sichtbaren Fehler verwandelt, und der Checklisten-Punkt Suche nicht mehr auf MySQL zurückfallen lassen ist die Kurzfassung.

Schritt 5: Ist das Frontend der langsame Teil?

Antwortet der Server schnell und die Seite fühlt sich trotzdem langsam an, messen Sie echte Besucher, bevor Sie das Theme anfassen. PageSpeed Insights zeigt Felddaten aus dem Chrome UX Report für URLs mit genug Traffic, darunter einen Lighthouse-Laborlauf. Google bewertet eine Seite als gut, wenn beim 75. Perzentil der Besuche Largest Contentful Paint (LCP) höchstens 2,5 Sekunden, Interaction to Next Paint (INP) höchstens 200 Millisekunden und Cumulative Layout Shift (CLS) höchstens 0,1 beträgt.

Die Serverzeit ist Teil des LCP, eine langsame TTFB begrenzt also, wie gut der LCP werden kann. Deshalb kommen die Server-Ebenen zuerst.

Die Checkliste enthält eine Frontend-Einstellung: Speculation Rules API einschalten, eine Einstellung in der Administration, verfügbar seit 6.6.10.0. Sobald ein Käufer mit der Maus über einen Link fährt oder ihn drückt, beginnt der Browser, die nächste Seite zu rendern, und der Klick landet auf einer Seite, die schon aufgebaut ist. Darüber hinaus hängt es vom Theme ab, was zu ändern ist. Bildgrößen, Schriften und Skripte von Drittanbietern sind die üblichen Stellen, und diese Anleitung hört beim Messen auf.

Vom Symptom zum Schritt

Dieselbe Reihenfolge gilt für Batch-Arbeit

Die Fallstudie zum Produktimport zeigt die Queue-Seite davon. Bei einem Katalog mit 530.000 SKUs dauerte ein vollständiger Produktabgleich 33 Stunden. Parallele Batches und ein Delta-Sync brachten ihn auf 2,8 Stunden. Die Details stehen in der Fallstudie zum Produktimport.