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

Backendy storage

P2Lab Cache zapisuje cache’owane odpowiedzi do jednego z trzech backendów storage. Wybierz jeden w Settings → Speed Boost → Core → Cache Storage → Cache Adapter. Możesz przełączyć w dowolnym momencie — przełączenie automatycznie czyści wpisy starego backendu.

Filesystem (domyślny)

Dział zatytułowany „Filesystem (domyślny)”

Zapisuje każdy wpis cache jako plik pod katalogiem cache Symfony (var/cache/...).

Plusy

  • Zero dodatkowej infrastruktury — działa od ręki
  • Łatwy do inspekcji z poziomu systemu plików
  • Niezawodny między workerami PHP-FPM
  • Rozmiar dysku jest raportowany dokładnie w dashboardzie

Minusy

  • Tylko single-server (każdy serwer ma własny filesystem)
  • Wolniejszy od backendów in-memory na hot pages
  • I/O dysku może być bottleneckiem pod ciężkim obciążeniem zapisu

Wybieraj, gdy: masz pojedynczy host Shopware, lub trzymasz osobny serwer cache, ale nie chcesz operować Redisem.

Redis

Dział zatytułowany „Redis”

Zapisuje wpisy cache w instancji Redis przez sieć. Skonfiguruj DSN w Core → Cache Storage → Redis DSN.

Przykłady DSN:

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

Opcjonalne pole Cache Namespace (domyślnie p2lab_cache) ustawia prefiks klucza, by wiele sklepów Shopware mogło dzielić jednego Redisa bez kolizji.

Plusy

  • Dzielone między wieloma hostami Shopware — prawdziwy klastrowy cache
  • Bardzo szybkie lookupy
  • Wbudowana obsługa TTL
  • Przetrwa restarty PHP-FPM

Minusy

  • Dodaje zależność operacyjną (instancja Redis do monitorowania i backupu)
  • Roundtrip sieciowy dodaje latency vs backendy in-process
  • Koszt pamięci rośnie z rozmiarem cache — ustaw Redisowi maxmemory i politykę evictionu

Wybieraj, gdy: masz więcej niż jeden host Shopware, lub już operujesz Redisem dla sesji / app cache i chcesz go reużyć.

APCu

Dział zatytułowany „APCu”

Zapisuje wpisy cache w shared memory procesu PHP APCu.

Plusy

  • Najszybszy backend na pojedynczym hoście — bez sieci, bez I/O plików
  • Bez dodatkowej infrastruktury poza rozszerzeniem PHP

Minusy

  • Process-local — każdy pool workerów PHP-FPM ma własny cache, więc HIT w jednym workerze to MISS w innym (aż oba wygenerują tę samą stronę)
  • Nie działa między serwerami — każdy host ma własne APCu
  • Znika przy restarcie PHP-FPM
  • Limit pamięci konfigurowany na poziomie PHP (apc.shm_size) — łatwo niedoszacować

Wybieraj, gdy: masz pojedynczy pool PHP-FPM na pojedynczym hoście, a obciążenie jest na tyle małe, że wszystkie hot pages mieszczą się komfortowo w shared memory.

Kompresja

Dział zatytułowany „Kompresja”

Wszystkie trzy backendy wspierają przełącznik Enable Cache Compression w Core → Cache Storage. Kompresja działa na zapisanym payloadzie, nie na transferze HTTP. Zobacz Kompresja.

Przełączanie backendów

Dział zatytułowany „Przełączanie backendów”

Aby przełączyć z jednego backendu na drugi:

  1. Otwórz Core → Cache Storage.
  2. Wybierz nowy adapter.
  3. Wypełnij odpowiednie pola (DSN dla Redisa).
  4. Zapisz.

Wpisy starego backendu stają się niedostępne — w końcu zostaną usunięte przez TTL, ale do tego czasu zajmują dysk / pamięć. Uruchom Dashboard → Clear all, by zwolnić stary store natychmiast, jeśli zależy Ci na miejscu.

Zakres kanału sprzedaży

Dział zatytułowany „Zakres kanału sprzedaży”

Ustawienie cache adapter można nadpisać per kanał sprzedaży z przełącznika w headerze, ale w praktyce niemal zawsze chcesz ten sam adapter dla całego sklepu. Mieszany setup (np. Redis dla głównego kanału, Filesystem dla staging) jest wspierany, ale dodaje złożoność operacyjną.

Powiązane

Dział zatytułowany „Powiązane”