Application cache and Redis #

This page is for developers and administrators who tune the caches behind a DXP site. Three caches are easy to mix up; this page separates them.

Contents #

1. Three caches
2. The content cache pool
3. Switching to Redis
4. Clearing each cache
5. Sessions

Three caches #

The content cache pool #

CACHE_POOL names the pool; the default is cache.tagaware.filesystem. An installed project keeps the predefined pools in config/packages/cache_pool/: cache.tagaware.filesystem.yaml, cache.redis.yaml and cache.memcached.yaml. Each siteaccess uses the pool set in ibexa.system.default.cache_service_name ('%cache_pool%'). A multi-repository installation needs a different pool per repository.

Switching to Redis #

CACHE_POOL=cache.redis
CACHE_DSN=redis://localhost:6379

Then clear the Symfony cache. Redis 6 or newer is the guide's minimum; it recommends Redis for production caching and sessions. Redis needs the PHP redis extension.

Clearing each cache #

php bin/console cache:clear --env=prod                    # Symfony cache
php bin/console cache:warmup --env=prod                   # build it again before traffic arrives
php bin/console cache:pool:clear cache.tagaware.filesystem   # the content pool (or cache.redis)
php bin/console fos:httpcache:invalidate:path / --all     # the HTTP cache

In development only, the guide's "nuclear option" removes var/cache/dev and var/cache/prod and warms up again. Do not delete cache directories on a production server under traffic; use the commands.

Sessions #

Sessions default to files under var/sessions/<env> (SESSION_HANDLER_ID=session.handler.native_file, SESSION_SAVE_PATH). On several web servers, sessions must be shared; Redis is a common choice. Change the handler in .env.local and test sign-in on every server.

Related pages #

• HTTP cache and Varnish
• Day-to-day commands
• Troubleshooting
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.