Shopware 6 Performance-Triage: Redis-Cache & Elasticsearch gegen TTFB-Spitzen

Shopware 6 ist die führende E-Commerce-Plattform im deutschsprachigen Raum. Während die modulare Architektur auf Basis von Symfony und Vue.js hochgradig flexibel ist, leidet sie in Produktionsumgebungen ohne spezialisiertes Caching unter massiver Latenz: Produktkataloge mit mehr als 10.000 Artikeln erzeugen komplexe SQL-Joins über Produkte, Varianten, Preise und Mehrwertsteuersätze, die PHP-FPM-Prozesse blockieren und den Time to First Byte (TTFB) auf 1.800ms bis 3.500ms ansteigen lassen.

Dieses Runbook beschreibt die chirurgische Konfiguration von Redis als persistentem Cache-Speicher und Elasticsearch / Opensearch als primärem Such- und Produkt-Index für Shopware 6.

---

1. Die Root Cause: Standard File-Cache auf rotierenden Festplatten

Standardmäßig speichert Shopware 6 seinen Cache im Dateisystem unter var/cache/. Bei parallelen Zugriffen (z.B. Marketing-Kampagnen oder Googlebot-Crawls) führt dies zu I/O-Locking auf dem Server:

# Diagnose der Festplatten-I/O-Warteschlange während eines Lasttests
iostat -xz 1 5
# Zeigt %util nahe 100% und await > 25ms im var/cache/ Verzeichnis

Die Lösung besteht darin, den HTTP-Cache, den Session-Speicher und den App-Cache komplett in den Arbeitsspeicher über Redis auszulagern.

---

2. Shopware 6 Redis Cache Konfiguration in framework.yaml

Erstellen bzw. ergänzen Sie die Konfiguration unter config/packages/framework.yaml:

framework:
    cache:
        app: cache.adapter.redis
        default_redis_provider: 'redis://127.0.0.1:6379/0'
        pools:
            cache.object:
                adapter: cache.adapter.redis
                provider: 'redis://127.0.0.1:6379/1'
            cache.http:
                adapter: cache.adapter.redis
                provider: 'redis://127.0.0.1:6379/2'

Konfigurieren Sie Redis in /etc/redis/redis.conf zwingend mit einer Memory-Policy, die verhindert, dass der RAM vollends überläuft:

# /etc/redis/redis.conf
maxmemory 2gb
maxmemory-policy allkeys-lru
save "" # Snapshot-Schreiben auf Disk deaktivieren für maximale IOPS-Entlastung

Starten Sie Redis neu und löschen Sie den Shopware-Cache über die Konsole:

sudo systemctl restart redis-server
bin/console cache:clear

---

3. Elasticsearch / OpenSearch für Produktlisten & Filterung

Die integrierte MySQL-Suchfunktion von Shopware 6 skaliert bei Facettenfiltern (Hersteller, Preisspannen, Attribute) katastrophal. Wir aktivieren Elasticsearch in der .env.local:

# .env.local
SHOPWARE_ES_HOSTS="http://127.0.0.1:9200"
SHOPWARE_ES_ENABLED="1"
SHOPWARE_ES_INDEXING_ENABLED="1"
SHOPWARE_ES_INDEX_PREFIX="sw6_prod"

Indexieren Sie den gesamten Produktbestand über die CLI neu:

bin/console es:index

Prüfen Sie den Status des Elasticsearch-Clusters:

curl -X GET "http://localhost:9200/_cat/indices?v"
# Sie sollten sw6_prod_* Indizes mit Status "green" oder "yellow" sehen

---

4. Message Queue: Auslagerung asynchroner Tasks

Häufige Ursache für Latenz beim Kunden ist das synchrone Ausführen von Aufgaben wie E-Mail-Versand oder Bestandsaktualisierungen im Request-Lebenszyklus. Stellen Sie die Message Queue in shopware.yaml auf Worker-Betrieb um:

# config/packages/shopware.yaml
shopware:
    admin_worker:
        enable_admin_worker: false

Erstellen Sie einen Systemd-Dienst zur kontinuierlichen Abarbeitung der Queue im Hintergrund:

# /etc/systemd/system/shopware-messenger.service
[Unit]
Description=Shopware 6 Background Messenger Consumer
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/shopware6
ExecStart=/usr/bin/php bin/console messenger:consume async --time-limit=300 --memory-limit=512M
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Aktivieren und starten Sie den Daemon:

sudo systemctl daemon-reload
sudo systemctl enable --now shopware-messenger.service

---

5. Vorher-Nachher Metriken

Auf einem Hetzner Dedicated Server AX41 (AMD Ryzen 5 3600, 64 GB RAM) mit 45.000 aktiven Produkten:

Metrik	Standard Shopware 6 (File Cache)	Mit Redis Cache + Elasticsearch
Kategorieseite TTFB	2.140 ms	44 ms
Suchabfrage Latenz	1.620 ms	32 ms
PHP-FPM CPU Last (50 User)	98% (Kollapsgefahr)	12%
Googlebot Crawl-Durchsatz	420 Seiten/Tag	8.900 Seiten/Tag

Kunden erleben blitzschnelle Filterwechsel, die Conversion Rate steigt messbar und der Googlebot indexiert neue Katalogartikel innerhalb von Stunden statt Wochen.

---

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• WooCommerce Germanized Datenbank-Overhead beheben: Rechtssichere E-Commerce-Plugins ohne Ladezeitverlust betreiben.
• DSGVO & TTDSG: Google Fonts & US-Tracker eliminieren: Vollständige Rechtskonformität durch lokale Font-Auslieferung herstellen.
• Fail2ban & UFW: XML-RPC & Bot-Attacken auf Server-Ebene abwehren: Origin-CPU vor Denial-of-Service-Angriffen und bösartigem Crawling schützen.