Troubleshooting

Meine Seiten sind immer MISS

Eine Handvoll häufiger Ursachen, nach Wahrscheinlichkeit:

1. Cache deaktiviert. Bestätigen Sie, dass Einstellungen → Speed Boost → Dashboard → Cache aktiviert an ist.
2. Route deaktiviert. Prüfen Sie den passenden Schalter in Dashboard → Cachefähige Routen.
3. Eingeloggte Session. Cache umgeht eingeloggte Kunden. In einem privaten Fenster testen.
4. Warenkorb-Cookie. Ein nicht leerer Warenkorb-Cookie umgeht ebenfalls. Warenkorb leeren.
5. Nicht ignorierter Query-Parameter. Ein Parameter nicht in der Liste Ignorierte Query-Parameter disqualifiziert die Anfrage. Hinzufügen.
6. Response setzt sensible Cookies. Manche Custom-Controller setzen pro-Besucher-Cookies, die den Cache umgehen. Mit curl -I inspizieren.
7. Falscher Sales-Channel-Geltungsbereich am Schalter. Globale und Pro-Channel-Einstellungen prüfen.

Core → Einstellungen → Debug-Modus an, um zu bestätigen: jede cachefähige Anfrage sollte beim zweiten Aufruf X-P2Lab-Cache-Status: HIT zurückgeben.

Mein Cache füllt sich, liefert aber nie einen HIT (Filesystem-Backend)

Das Filesystem-Backend liegt unter Shopwares Symfony-Cache-Verzeichnis. Zwei Dinge können es brechen:

• bin/console cache:clear wurde aufgerufen — das wischt den Symfony-Cache, inklusive unseres. Neu aufwärmen.
• Unterschiedliche Filesystem-Pfade pro Server — ein Multi-Host-Setup mit Filesystem-Backend ist nicht geteilt. Zu Redis wechseln.

Redis-Backend kann sich nicht verbinden

Prüfen:

• DSN-Format — redis://[user[:password]@]host[:port][/db]
• Die Redis-Instanz ist vom PHP-Host erreichbar (telnet host 6379)
• Redis ist nicht voll und lehnt neue Schreibvorgänge ab
• maxmemory-policy erlaubt Eviction (allkeys-lru ist typisch)
• Cache-Namespace kollidiert nicht mit einer anderen App auf derselben Redis-Instanz (eindeutigen cacheNamespace setzen)

Das Plugin loggt Redis-Verbindungsfehler ins Standard-Symfony-Log.

APCu-Backend liefert stale oder MISS inkonsistent

APCu ist pro PHP-FPM-Worker-Pool. Jeder Pool hat seinen eigenen Speicherbereich. Mehrere Pools = mehrere unabhängige Caches. Auf Redis oder Filesystem wechseln, wenn pool-übergreifende Konsistenz wichtig ist.

Auch apc.shm_size prüfen — zu klein, und Einträge werden lange vor TTL evicted.

Warmup steht bei 0 %

Der Warmup läuft über die Async Message Queue. Verifizieren:

bin/console messenger:consume async --time-limit=10

Wenn der Befehl untätig dasitzt, dispatched die Queue nicht — Messenger-Transport-Konfiguration prüfen.

Wenn Sie sehen, dass Warmup-Messages verarbeitet werden, der Geprüft-Zähler sich aber nicht bewegt, läuft der Worker, aber die HTTP-Anfragen scheitern. Schauen Sie in Warmup-Historie → Detail nach fehlgeschlagenen URLs und ihren Statuscodes.

Varnish wird nicht gepurged

Der Reihe nach:

1. Bestätigen, dass Shopware selbst für den Reverse Proxy konfiguriert ist (shopware.http_cache.reverse_proxy.enabled: true).
2. Bestätigen, dass der xkey-VMOD in Varnish geladen ist.
3. Einstellungen → Speed Boost → Reverse Proxy → Varnish-Cache aktivieren muss an sein.
4. Reverse-Proxy-Log aktivieren und einen Save im Admin auslösen. Eine Zeile sollte mit Purge-Details erscheinen.
5. Wenn das Log den Purge zeigt, Varnish aber weiterhin stale ausliefert, prüfen Sie Varnishs xkey-Konfiguration — Purge-Endpoint, Tag-Matching-Pattern usw.

Smart-Modus invalidiert zu viel / zu wenig

• Zu viel — meist Massenimport oder DAL-Write mit vollem Payload. Smart kann nicht erkennen, welche Felder sich wirklich geändert haben, und purged so, als ob jedes getrackte Feld geändert wäre. Für Massenimporte Precise nutzen.
• Zu wenig — Ihr Custom-Feld oder Theme-Template liest einen Wert, den der Analyzer nicht kennt. SmartInvalidationAnalyzer decoraten, um das Mapping hinzuzufügen, oder für den betroffenen Entitätstyp auf Extended zurückfallen.

Invalidierungslog aktivieren, um zu sehen, was jeder Save genau invalidiert.

Dashboard zeigt die falsche Größe

Für das Filesystem-Backend verwendet das Dashboard die tatsächliche Festplattengröße. Für Redis / APCu verwendet es den in p2lab_cache_entry gespeicherten Wert. Nach Backend-Wechsel oder nach cache:clear können die Metadaten driften.

Beheben durch manuelles Ausführen des Cleanup-Tasks:

bin/console scheduled-task:run-single p2lab_cache.cleanup_cache_entries

Dann das Dashboard neu laden.

Logs sind riesig

Die drei Log-Tabellen (p2lab_cache_invalidation_log, p2lab_cache_reverse_proxy_log, p2lab_cache_warmup_failed_url) werden automatisch nach 30 Tagen von Scheduled Tasks geprunt. Wenn sie ungebremst wachsen, bestätigen:

bin/console messenger:consume scheduler --time-limit=10

Wenn der Scheduler nicht läuft, feuern die Tasks nie.

Plugin vorübergehend deaktivieren

Um P2Lab Cache zu umgehen, ohne zu deinstallieren — nützlich, wenn Sie einem möglicherweise cache-bedingten Bug nachjagen:

1. Dashboard → Cache aktiviert → aus
2. Reverse Proxy → Varnish-Cache aktivieren → aus (damit Varnish nicht mehr auf Plugin-Tag-Basis purged)
3. Optional: bin/console p2lab:cache:clear, um bestehende Einträge zu löschen

Später wieder aktivieren. Kein Restart erforderlich.

Trotzdem nicht weiter?

Sammeln Sie:

• Die Plugin-Version (composer show p2lab/cache oder Erweiterungen → Meine Erweiterungen)
• Die Shopware-Version
• Den gewählten Cache-Adapter
• Einen repräsentativen Eintrag aus Invalidierungs- und Reverse-Proxy-Log
• Eine Antwort mit Debug-Headern (X-P2Lab-Cache-*)

Wenden Sie sich an Ihren Distributor mit diesem Bundle. Die meisten Probleme lassen sich aus diesen fünf Inputs lösen.

Verwandt

• Logs & Monitoring
• Smart-Invalidierung im Detail
• Reverse Proxy (Varnish)