Choosing a Caching Backend for TYPO3 v11 LTS: Redis, APCu, or File‑based

Decision and Constraints

When operating a TYPO3 v11 LTS site you may need to improve response times by selecting an appropriate caching backend. The decision must respect the following constraints:

• TYPO3 version ≥ 11.5 (LTS)
• Server runs Linux with PHP ≥ 8.0
• Requirement for distributed caching across multiple web nodes (e.g., a load‑balanced cluster)

Given these constraints, the viable options are Redis, APCu, and the built‑in file‑based backend. The following guide compares them, outlines trade‑offs, and provides a concrete configuration example.

Comparison of Caching Backends

Backend	Persistence	Network Access	Tagging Support	Typical Latency	Operational Overhead
Redis	Yes (optional AOF/RDB)	Yes – TCP socket	Yes	Low‑moderate (network hop)	Medium – separate daemon, security, monitoring
APCu	No – process‑local	No – shared memory only on same host	No	Very low (in‑process)	Low – PHP extension only
File‑based	Yes – disk	No – local filesystem	No	Moderate‑high (I/O bound)	Low – no extra services

Trade‑offs

Redis offers the best scalability for multi‑node setups because the cache lives on a central server that all web nodes can reach. It also supports cache tags, which TYPO3 uses for fine‑grained invalidation (e.g., when a page is edited). The downside is the need to run, secure, and monitor a Redis instance, and the added network latency compared to pure in‑memory solutions.

APCu provides the lowest latency because the cache resides in the PHP process’s shared memory. However, it is strictly node‑local: each web server maintains its own copy, making cross‑node cache warming impossible and leading to inconsistent caches unless you employ sticky sessions or a separate mechanism to propagate changes. APCu also does not support TYPO3’s tagging feature.

File‑based caching is the simplest to enable—no extra packages or PHP extensions are required. It works on any host with writable filesystem space. Under heavy load, disk I/O can become a bottleneck, and the lack of tagging means cache clearing is less precise.

Implementation Steps

Below is an example configuration for using Redis as the caching backend for the cache_pages cache (the frontend page cache). Place the code in AdditionalConfiguration.php (typically located in typo3conf/).

// AdditionalConfiguration.php
// Use Redis for the page cache
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_pages'] = [
    'backend' => \\TYPO3\\CMS\\Core\\Cache\\Backend\\RedisBackend::class,
    'options' => [
        'host' => 'redis.example.com',   // replace with your Redis host
        'port' => 6379,                  // default Redis port
        'timeout' => 3.0,                // connection timeout in seconds
        // If your Redis instance requires authentication:
        // 'password' => 'yourStrongPassword',
        // Optional: select a specific database (0‑15)
        // 'database' => 2,
    ],
];

If you prefer APCu for a single‑node setup, replace the backend class and options accordingly:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_pages'] = [
    'backend' => \\TYPO3\\CMS\\Core\\Cache\\Backend\\ApcuBackend::class,
    'options' => [],
];

For the file‑based backend (the default), you can explicitly set:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_pages'] = [
    'backend' => \\TYPO3\\CMS\\Core\\Cache\\Backend\\FileBackend::class,
    'options' => [
        'cacheDir' => 'typo3temp/var/cache/',
    ],
];

Validation and Checks

After saving AdditionalConfiguration.php, clear the TYPO3 cache to ensure the new settings are loaded:

# Run from the TYPO3 root directory
php vendor/bin/typo3cms cache:flush

You can verify the active backend via the Install Tool:

1. Navigate to System > Configuration in the TYPO3 backend.
2. Search for SYS.caching.cacheConfigurations.cache_pages.backend.
3. The displayed value should match the class you set (e.g., TYPO3\\CMS\\Core\\Cache\\Backend\\RedisBackend).

Additionally, you can inspect the cache directory or Redis keys to confirm that entries are being stored:

• For Redis: redis-cli -h redis.example.com -p 6379 KEYS "typo3_*" (adjust host/port as needed).
• For file‑based: list files under typo3temp/var/cache/.

To assess performance impact, run a simple benchmark on a cached page before and after the switch (e.g., using ab or wrk). Compare average response times; a reduction indicates the backend is functioning.

Finally, test tag‑based invalidation (only relevant for Redis): edit a page in the backend, then run the warmup command and verify that only the affected cache entries are cleared:

php vendor/bin/typo3cms cache:warmup

Monitor the Redis key space; entries related to the edited page should disappear while unrelated entries remain.

Limitations

• Redis adds an external dependency; ensure it is protected by a firewall and requires a strong password if exposed.
• APCu size is governed by apc.shm_size in php.ini. Exceeding this limit causes cache evictions and fallback to slower backends.
• File‑based caching can exhaust disk space if not rotated; consider a cron job to prune old cache files.

By following the steps above you can make an informed decision, apply the chosen backend, and verify that TYPO3 is using it as intended.