Skip to content
P2Lab Cache

Storage backends

P2Lab Cache writes cached responses to one of three storage backends. Pick one in Settings → Speed Boost → Core → Cache Storage → Cache Adapter. You can switch at any time — switching clears the old backend’s entries automatically.

Filesystem (default)

Section titled “Filesystem (default)”

Stores each cache entry as a file under the Symfony cache directory (var/cache/...).

Pros

  • Zero extra infrastructure — works out of the box
  • Easy to inspect with the file system
  • Reliable across PHP-FPM workers
  • Disk size is reported accurately in the dashboard

Cons

  • Single-server only (each server has its own filesystem)
  • Slower than in-memory backends on hot pages
  • Disk I/O can become a bottleneck under heavy write load

Pick when: you run a single Shopware host, or you keep a separate cache server but don’t want to operate Redis.

Redis

Section titled “Redis”

Stores cache entries in a Redis instance over the network. Configure with a DSN under Core → Cache Storage → Redis DSN.

DSN examples:

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

The optional Cache Namespace field (default p2lab_cache) sets the key prefix so multiple Shopware stores can share the same Redis without colliding.

Pros

  • Shared across multiple Shopware hosts — true cluster cache
  • Very fast lookups
  • Built-in TTL handling
  • Survives PHP-FPM restarts

Cons

  • Adds an operational dependency (Redis instance to monitor and back up)
  • Network round-trip adds latency vs in-process backends
  • Memory cost grows with cache size — set Redis maxmemory and an eviction policy

Pick when: you run more than one Shopware host, or you already operate Redis for sessions / app cache and want to reuse it.

APCu

Section titled “APCu”

Stores cache entries in the PHP process’s APCu shared memory.

Pros

  • Fastest backend on a single host — no network, no file I/O
  • No extra infrastructure beyond the PHP extension

Cons

  • Process-local — every PHP-FPM worker pool maintains its own cache, so a HIT in one worker is a MISS in another (until both have generated the same page)
  • Does not work across servers — each host has its own APCu
  • Disappears on PHP-FPM restart
  • Memory cap configured at the PHP level (apc.shm_size) — easy to undersize

Pick when: you run a single PHP-FPM pool on a single host and the workload is small enough that all hot pages fit comfortably in shared memory.

Compression

Section titled “Compression”

All three backends support the Enable Cache Compression toggle under Core → Cache Storage. Compression applies to the stored payload, not the HTTP transfer. See Compression.

Switching backends

Section titled “Switching backends”

To switch from one backend to another:

  1. Open Core → Cache Storage.
  2. Pick the new adapter.
  3. Fill in the relevant fields (DSN for Redis).
  4. Save.

The old backend’s entries become inaccessible — they will eventually be evicted by TTL but until then they take up disk / memory. Run Dashboard → Clear all to free the old store immediately if you care about the disk space.

Sales-channel scope

Section titled “Sales-channel scope”

The cache adapter setting can be overridden per sales channel from the page-header switcher, but in practice you almost always want the same adapter for the whole shop. A mixed setup (e.g. Redis for the main channel, Filesystem for staging) is supported but adds operational complexity.

Section titled “Related”