Zum Inhalt springen
P2Lab Cache

Storage-Backends

P2Lab Cache schreibt gecachte Antworten in eines von drei Storage-Backends. Wählen Sie eins unter Einstellungen → Speed Boost → Core → Cache-Speicher → Cache-Adapter. Sie können jederzeit wechseln — beim Wechsel werden die Einträge des alten Backends automatisch gelöscht.

Filesystem (Standard)

Abschnitt betitelt „Filesystem (Standard)“

Speichert jeden Cache-Eintrag als Datei unter dem Symfony-Cache-Verzeichnis (var/cache/...).

Vorteile

  • Keine zusätzliche Infrastruktur — funktioniert out of the box
  • Einfach mit dem Dateisystem zu inspizieren
  • Zuverlässig über PHP-FPM-Worker hinweg
  • Festplattengröße wird im Dashboard exakt ausgewiesen

Nachteile

  • Nur Single-Server (jeder Server hat sein eigenes Dateisystem)
  • Langsamer als In-Memory-Backends bei Hot Pages
  • Disk-I/O kann unter starker Schreiblast zum Engpass werden

Wählen, wenn: Sie einen einzigen Shopware-Host betreiben oder einen separaten Cache-Server haben, aber Redis nicht betreiben wollen.

Redis

Abschnitt betitelt „Redis“

Speichert Cache-Einträge in einer Redis-Instanz übers Netzwerk. Konfigurieren Sie das DSN unter Core → Cache-Speicher → Redis DSN.

DSN-Beispiele:

redis://localhost:6379
redis://:passwort@cache.internal:6379/2
redis://localhost:6379?timeout=2&persistent_id=p2lab

Das optionale Feld Cache-Namespace (Standard p2lab_cache) setzt das Key-Prefix, damit mehrere Shopware-Shops dieselbe Redis-Instanz kollisionsfrei nutzen können.

Vorteile

  • Geteilt über mehrere Shopware-Hosts — echter Cluster-Cache
  • Sehr schnelle Lookups
  • Eingebaute TTL-Behandlung
  • Überlebt PHP-FPM-Neustarts

Nachteile

  • Fügt eine operative Abhängigkeit hinzu (Redis-Instanz monitoren und sichern)
  • Netzwerk-Roundtrip fügt Latenz vs. In-Process-Backends hinzu
  • Speicheraufwand wächst mit Cache-Größe — maxmemory und Eviction-Policy für Redis setzen

Wählen, wenn: Sie mehr als einen Shopware-Host betreiben oder Redis bereits für Sessions / App-Cache nutzen und wiederverwenden möchten.

APCu

Abschnitt betitelt „APCu“

Speichert Cache-Einträge im Shared Memory des PHP-Prozesses (APCu).

Vorteile

  • Schnellstes Backend auf einem Single-Host — kein Netz, kein Datei-I/O
  • Keine zusätzliche Infrastruktur über die PHP-Erweiterung hinaus

Nachteile

  • Prozesslokal — jeder PHP-FPM-Worker-Pool hält seinen eigenen Cache; ein HIT in einem Worker ist ein MISS im anderen (bis beide die gleiche Seite generiert haben)
  • Funktioniert nicht über Server hinweg — jeder Host hat sein eigenes APCu
  • Verschwindet bei PHP-FPM-Neustart
  • Speicherobergrenze auf PHP-Ebene konfiguriert (apc.shm_size) — leicht zu unterdimensionieren

Wählen, wenn: Sie einen einzigen PHP-FPM-Pool auf einem einzigen Host betreiben und die Last so klein ist, dass alle Hot Pages bequem in den Shared Memory passen.

Komprimierung

Abschnitt betitelt „Komprimierung“

Alle drei Backends unterstützen den Schalter Cache-Komprimierung aktivieren unter Core → Cache-Speicher. Komprimierung wirkt auf den gespeicherten Payload, nicht auf den HTTP-Transfer. Siehe Komprimierung.

Backend-Wechsel

Abschnitt betitelt „Backend-Wechsel“

Um von einem Backend zum anderen zu wechseln:

  1. Core → Cache-Speicher öffnen.
  2. Neuen Adapter wählen.
  3. Relevante Felder ausfüllen (DSN für Redis).
  4. Speichern.

Die Einträge des alten Backends werden unzugänglich — sie werden irgendwann per TTL entfernt, belegen aber bis dahin Platz / Speicher. Führen Sie Dashboard → Alle leeren aus, um den alten Speicher sofort freizugeben.

Sales-Channel-Geltungsbereich

Abschnitt betitelt „Sales-Channel-Geltungsbereich“

Die Cache-Adapter-Einstellung lässt sich pro Sales Channel über den Seitenkopf-Switcher überschreiben, in der Praxis wollen Sie aber fast immer denselben Adapter für den ganzen Shop. Ein gemischtes Setup (z. B. Redis für den Hauptkanal, Filesystem für Staging) wird unterstützt, fügt aber operative Komplexität hinzu.

Verwandt

Abschnitt betitelt „Verwandt“