Skip to content
P2Lab Cache

Cache warming

After a deployment, a full Clear cache, or a wholesale invalidation, your cache is empty. The first visitor to each page pays the full render cost (MISS). Cache warming pre-generates every cacheable URL ahead of time, so visitors only ever see cached responses.

The warmup is driven by the Symfony message queue — the dispatching request returns immediately, then the worker chews through URLs in the background. Progress is tracked in the database and surfaced live in the admin.

How to start a warmup

Section titled “How to start a warmup”
  1. Open Settings → Speed Boost → Dashboard.
  2. Click Start warmup.
  3. (Optional) Override the Batch size (default 50).
  4. Confirm. The warmup is dispatched to the queue.

The dashboard displays:

  • Total URLs — discovered cacheable URLs at the start
  • Checked — how many were processed so far (success or failure)
  • Remaining — URLs still in flight
  • Percentage complete
  • A real-time per-type cache stats panel that updates as entries are written

You can Pause, Resume or Cancel at any time from the dashboard.

What gets warmed

Section titled “What gets warmed”

The warmup discovery query collects every URL the cache can handle:

  • Active products visible to each sales channel (deduplicated against seo_url)
  • Active categories that are part of a navigation tree (deduplicated against seo_url)
  • CMS pages assigned to a sales channel
  • The home page of each sales channel

The query honours visibility flags, sales-channel scope and SEO-url uniqueness — disabled or invisible URLs are skipped.

Per-sales-channel warmups

Section titled “Per-sales-channel warmups”

The warmup respects the sales-channel switcher in the page header. If you pick a single sales channel before starting, only that channel’s URLs are warmed. With “All sales channels” selected, the warmup covers every active channel.

Async queue requirement

Section titled “Async queue requirement”

Warming runs on top of Symfony Messenger. The async worker must be running:

Terminal window
bin/console messenger:consume async --time-limit=300

In production, run the worker as a long-lived process (systemd, supervisor, or whatever you already use for Shopware’s other async jobs). Without a running worker, the warmup will sit in the queue forever — the Start warmup request still succeeds and the progress entry is created, but Checked stays at 0.

Failed URLs

Section titled “Failed URLs”

When a URL returns a non-2xx HTTP status, it’s counted as a failure but doesn’t stop the warmup. Failed URLs are listed in Warmup history → Detail for the run, with their status code and a snippet of the response.

Common reasons:

  • A redirect chain (e.g. an old SEO URL → 301 → new SEO URL) — these are usually fine
  • A category with no visible products (returns 404 in some themes)
  • A CMS page hidden from the storefront via permissions
  • An infrastructure error (502 / 504) — re-run the warmup once the underlying issue is fixed

Warmup history

Section titled “Warmup history”

Every warmup run creates a row in Warmup history:

  • Started / finished timestamps
  • Total / checked / failed counts
  • Average HTTP response time
  • Status (running / paused / cancelled / completed)

The detail view drills into individual URLs and their results. History is retained indefinitely — clear it manually if you don’t need it.

HTTPS, scheme and hostname

Section titled “HTTPS, scheme and hostname”

The warmup hits URLs through HTTP by default. If you want to warm HTTPS URLs (typical for production), make sure the storefront domain in Sales Channels → Domains uses https:// — the warmup follows that scheme.

Triggering warmups from a deployment script

Section titled “Triggering warmups from a deployment script”

To warm the cache as part of a deploy pipeline, hit the REST endpoint:

Terminal window
curl -X POST https://your-shop.example.com/api/_action/p2lab-cache/warmup/start \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"salesChannelId":null,"batchSize":100}'

The response includes a progressId you can poll via /api/_action/p2lab-cache/warmup/progress?progressId=… to wait for completion.

See REST API for the full endpoint list.

Throughput tips

Section titled “Throughput tips”
  • Increase batch size if your message worker is fast and you want to finish quicker. Default 50 is conservative.
  • Run multiple workers — messenger:consume async --limit=… can run in parallel processes; the warmup will spread across them.
  • Disable invalidation logging during a warmup if your invalidation log database is on slow disk — the dashboard provides the same numbers in memory.
Section titled “Related”