Przejdź do głównej zawartości
P2Lab Cache

Troubleshooting

Moje strony zawsze MISSują

Dział zatytułowany „Moje strony zawsze MISSują”

Garść częstych przyczyn, w kolejności prawdopodobieństwa:

  1. Cache wyłączony. Potwierdź, że Settings → Speed Boost → Dashboard → Cache enabled jest on.
  2. Trasa wyłączona. Sprawdź pasujący przełącznik w Dashboard → Cacheable Routes.
  3. Zalogowana sesja. Cache bypassuje zalogowanych klientów. Przetestuj w trybie incognito.
  4. Cookie koszyka. Niepuste cookie koszyka też bypassuje. Wyczyść koszyk.
  5. Nieignorowany parametr query. Parametr nie z listy Ignored Query Parameters dyskwalifikuje żądanie. Dodaj go.
  6. Odpowiedź ustawia wrażliwe cookies. Niektóre custom kontrolery ustawiają per-odwiedzający cookies, które bypassują cache. Sprawdź z curl -I.
  7. Zły zakres kanału sprzedaży na przełączniku. Sprawdź zarówno globalne, jak i per-kanałowe ustawienia.

Włącz Core → Settings → Debug Mode, by potwierdzić: każde cache’owalne żądanie powinno teraz zwracać X-P2Lab-Cache-Status: HIT przy drugim trafieniu.

Mój cache się wypełnia, ale nigdy nie serwuje HIT (backend Filesystem)

Dział zatytułowany „Mój cache się wypełnia, ale nigdy nie serwuje HIT (backend Filesystem)”

Backend Filesystem żyje pod katalogiem cache Symfony Shopware. Dwie rzeczy mogą go zepsuć:

  • bin/console cache:clear został wywołany — to wymazuje cache Symfony, w tym nasz. Nagrzej ponownie.
  • Różne ścieżki filesystem per serwer — multi-host setup z backendem Filesystem nie jest dzielony. Przełącz na Redis.

Backend Redis nie chce się połączyć

Dział zatytułowany „Backend Redis nie chce się połączyć”

Sprawdź:

  • Format DSN — redis://[user[:password]@]host[:port][/db]
  • Instancja Redis jest osiągalna z hosta PHP (telnet host 6379)
  • Redis nie wyczerpał pamięci i nie odrzuca nowych zapisów
  • maxmemory-policy zezwala na eviction (allkeys-lru jest typowe)
  • Cache namespace nie koliduje z inną aplikacją na tym samym Redisie (ustaw unikalny cacheNamespace)

Plugin loguje błędy połączenia Redis do standardowego logu Symfony.

Backend APCu serwuje stale lub MISSuje niespójnie

Dział zatytułowany „Backend APCu serwuje stale lub MISSuje niespójnie”

APCu jest per pool workerów PHP-FPM. Każdy pool ma własny obszar pamięci. Wiele poolów = wiele niezależnych cache. Przełącz na Redis lub Filesystem, jeśli potrzebujesz spójności między poolami.

Sprawdź też apc.shm_size — za małe i wpisy są usuwane długo przed TTL.

Warmup utknął na 0%

Dział zatytułowany „Warmup utknął na 0%”

Warmup działa na async message queue. Zweryfikuj:

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

Jeśli komenda siedzi bezczynnie, kolejka nie dispatchuje — sprawdź konfigurację transportu messenger.

Jeśli widzisz, że message warmupu są przetwarzane, ale licznik Checked się nie rusza, worker działa, ale żądania HTTP failują. Spójrz na Warmup history → Detail dla failed URLs i ich statusów.

Varnish nie jest purgowany

Dział zatytułowany „Varnish nie jest purgowany”

W kolejności:

  1. Potwierdź, że sam Shopware jest skonfigurowany na reverse proxy (shopware.http_cache.reverse_proxy.enabled: true).
  2. Potwierdź, że vmod xkey jest załadowany w Varnishu.
  3. Settings → Speed Boost → Reverse proxy → Enable Varnish Cache musi być on.
  4. Włącz Reverse Proxy Log i triggeruj save w panelu. Wiersz powinien pojawić się ze szczegółami purge.
  5. Jeśli log pokazuje purge, ale Varnish wciąż serwuje stale, sprawdź konfigurację xkey Varnisha — endpoint purge, wzorzec matchowania tagów itp.

Tryb Smart inwaliduje za dużo / za mało

Dział zatytułowany „Tryb Smart inwaliduje za dużo / za mało”
  • Za dużo — zwykle bulk import lub zapis DAL wysyłający pełny payload. Smart nie może powiedzieć, które pola naprawdę się zmieniły, więc purguje, jakby każde śledzone pole. Użyj Precise dla bulk importów.
  • Za mało — Twoje pole custom lub template theme czyta wartość, której analyzer nie zna. Dekoruj SmartInvalidationAnalyzer, by dodać mapowanie, lub spadnij do Extended dla dotkniętego typu encji.

Włącz Invalidation Log, by zobaczyć dokładnie, co każdy save inwaliduje.

Dashboard pokazuje zły rozmiar

Dział zatytułowany „Dashboard pokazuje zły rozmiar”

Dla backendu Filesystem dashboard używa faktycznego rozmiaru dysku. Dla Redis / APCu używa wartości zapisanej w p2lab_cache_entry. Po przełączeniu backendów lub po cache:clear metadane mogą się rozjeżdżać.

Napraw uruchamiając zadanie czyszczące ręcznie:

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

Potem odśwież dashboard.

Logi są ogromne

Dział zatytułowany „Logi są ogromne”

Trzy tabele logów (p2lab_cache_invalidation_log, p2lab_cache_reverse_proxy_log, p2lab_cache_warmup_failed_url) są pruowane automatycznie po 30 dniach przez zaplanowane zadania. Jeśli rosną bez ograniczeń, potwierdź:

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

Jeśli scheduler nie działa, zadania nigdy nie odpalają.

Tymczasowe wyłączenie pluginu

Dział zatytułowany „Tymczasowe wyłączenie pluginu”

By obejść P2Lab Cache bez deinstalacji — przydatne, gdy goniąc bug, który może być cache-related:

  1. Dashboard → Cache enabled → off
  2. Reverse proxy → Enable Varnish Cache → off (by Varnish przestał purgować po tagach pluginu)
  3. Opcjonalnie: bin/console p2lab:cache:clear, by upuścić istniejące wpisy

Włącz później ponownie. Bez restartu.

Wciąż utknięty?

Dział zatytułowany „Wciąż utknięty?”

Zbierz:

  • Wersję pluginu (composer show p2lab/cache lub Extensions → My extensions)
  • Wersję Shopware
  • Wybrany cache adapter
  • Reprezentatywny wpis z logu Invalidation i Reverse-proxy
  • Odpowiedź z nagłówkami debug (X-P2Lab-Cache-*)

Skontaktuj się z dystrybutorem z tym bundle. Większość problemów da się rozwiązać z tych pięciu inputów.

Powiązane

Dział zatytułowany „Powiązane”