How to use Redis, OpCache, and PHP‑FPM tuning with Shopware 6?
Quick Answer
Shopware 6 runs noticeably faster when you combine Redis object caching, properly sized PHP OpCache, and tuned PHP-FPM worker settings. Most slow storefronts are not limited by Shopware itself—they are limited by poor PHP process management, cold cache misses, and overloaded database queries. The setup below covers the server-side tuning changes we apply most often on high-traffic Shopware stores.
Before You Start
- ✦ Root or SSH access — you’ll need to edit PHP-FPM, Redis, and server config files directly.
- ✦ Production mode enabled — tuning a development environment gives misleading performance results.
- ✦ Monitoring access — tools like New Relic, Netdata, or htop help validate whether changes actually improved throughput.
Enable Redis caching
Redis reduces repeated database and filesystem lookups by storing cached objects in memory. On busy Shopware stores, this lowers response times significantly during catalog browsing and checkout sessions. We normally use Redis for sessions and Symfony cache pools together. That combination gives the biggest win for the least effort.
- Install Redis on the application server
- Enable Redis session storage in Shopware
- Point Symfony cache pools to Redis
SHOPWARE_CACHE_ID=prod
REDIS_URL=redis://127.0.0.1:6379Tune PHP OpCache
OpCache keeps compiled PHP bytecode in memory so PHP does not recompile files on every request. Most default hosting environments allocate far too little memory for Shopware 6. That creates constant cache eviction and slower response times during traffic spikes.
- Increase opcache.memory_consumption to at least 256MB
- Enable opcache.validate_timestamps in staging only
- Restart PHP-FPM after changes
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=30000
opcache.validate_timestamps=0Optimise PHP-FPM workers
PHP-FPM controls how many PHP processes can handle requests at the same time. If worker counts are too low, your storefront queues requests during traffic spikes. If they are too high, the server runs out of RAM and starts swapping memory to disk. Both situations slow Shopware down badly.
- Use pm=dynamic for most stores
- Calculate pm.max_children from available RAM
- Monitor worker saturation during peak traffic
Warm and monitor caches
Performance tuning is not finished after changing config values. You need to warm caches and monitor real storefront traffic. We usually benchmark homepage, product detail, and cart pages before and after changes. That exposes whether the bottleneck is PHP, MySQL, Elasticsearch, or external APIs.
- Clear and warm Shopware cache after deployment
- Track PHP response times during peak traffic
- Review slow query logs weekly
Shopware Performance Tuning Checklist
0 of 6 completeMistakes Most Developers Make
! Oversizing PHP workers
What happens: The server runs out of RAM and response times spike during traffic peaks.
Fix: Base worker counts on real memory usage instead of CPU core count.
! Forgetting cache warm-up
What happens: First visitors after deployment experience slow uncached page loads.
Fix: Run cache warm-up scripts immediately after deployment finishes.
Key Takeaway
The short version: Shopware 6 performance depends heavily on server-side tuning, not just frontend optimisation. Redis removes repeated database work, OpCache prevents unnecessary PHP compilation, and PHP-FPM tuning keeps traffic spikes from overwhelming the server. Most stores improve stability fastest by fixing worker sizing and cache configuration first. Start with Step 3—that one alone handles most of it.
Related Answers
Was this answer helpful?
Your feedback helps us improve our answers.
Still need help?
Talk to our Shopware experts
We've handled GDPR/CCPA compliance for dozens of EU & US Shopware stores.