Optimising Drupal Performance With a Redis Cache Backend
Drupal sites can become noticeably slower as content, users, views, search indexes, and contributed modules accumulate. PHP workers spend time rebuilding render arrays, database queries repeat across requests, and authenticated sessions create extra work. A Redis cache backend gives Drupal a fast in-memory store for data that would otherwise be read from MySQL or PostgreSQL on every page load.
Redis is particularly useful for busy Australian websites serving visitors across Sydney, Melbourne, Brisbane, Perth, and regional areas. The best results come from treating it as one component of a wider performance strategy: sensible cache configuration, efficient hosting, correct PHP settings, and monitoring that shows whether the cache is helping in real conditions.
How Redis Fits Into Drupal Caching
Drupal divides cached information into separate cache bins. Rendered page fragments, dynamic page data, discovery information, configuration, data from Views, and other temporary records can each use a different bin. With the appropriate Redis integration, these bins are stored in Redis rather than in database tables.
Redis keeps values in memory and retrieves them through a lightweight network protocol. A cache lookup is generally much cheaper than opening a database connection, parsing a query, checking indexes, and transferring rows. This reduces database pressure and leaves more capacity for content searches, editorial activity, and requests that genuinely need database work.
Drupal’s cache tags and cache invalidation still apply when Redis is used. When an editor updates an article, Drupal can invalidate related render cache entries instead of forcing every cached page to expire at the same time. This is important for publishers, government sites, and retailers where content changes need to appear promptly without disabling caching across the whole site.
Redis is not a replacement for Drupal’s internal cache system. It is a storage backend for that system. Drupal continues to decide what can be cached, when a value is stale, and which tags should be invalidated.
Choosing A Suitable Redis Setup
A production Redis service should normally run separately from the web process, although it may be installed on the same server for a small site. The PHP application connects to Redis using the PhpRedis extension or, in some environments, a compatible client library. The native PhpRedis extension is usually preferred because it is compiled code with low overhead and broad support in modern PHP hosting environments.
Managed Redis can be a practical option for Australian organisations that host Drupal in Sydney or Melbourne availability zones. It reduces the operational work involved in backups, failover, patching, and monitoring. A Brisbane business hosting its application in Sydney may accept a small network delay, but Redis should still be placed close to the web servers. A cache service located overseas can add latency to every cache operation and undermine the reason for using it.
Security matters because Redis is not designed to be exposed directly to the public internet. Bind it to a private interface, restrict access with firewall rules or security groups, and use authentication or TLS where the hosting platform supports it. The Redis port should never be open broadly simply because the server is behind a router or cloud network.
Memory limits also need careful planning. Configure a maximum memory policy suitable for cache data, commonly allkeys-lru when Redis contains disposable cache entries. Avoid storing Drupal cache data in the same Redis database as queues, application locks, or unrelated services unless the eviction and capacity requirements are fully understood. A cache eviction can be inconvenient; eviction of locks or session data can create harder-to-diagnose failures.
Installing And Connecting The Drupal Redis Module
The Drupal Redis project provides the integration needed to use Redis for cache bins and related services. Install it with Composer from the Drupal project directory:
composer require drupal/redis
The module’s current documentation should be checked against the installed Drupal core and PHP versions. Enable it with Drush, then copy or adapt the Redis service definitions supplied by the module. Drupal sites often use sites/default/default.services.yml as a reference and place active overrides in sites/default/services.yml.
A typical settings.php configuration may resemble the following:
$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;
$settings['redis.connection']['password'] = getenv('REDIS_PASSWORD');
$settings['cache']['default'] = 'cache.backend.redis';
The exact variable names and service configuration can vary between module releases, so the installed module’s example settings file takes precedence over copied snippets. For a remote Redis service, use its private hostname rather than a public address, and configure the correct database number, TLS settings, and connection timeout.
After changing services or settings, rebuild Drupal’s caches:
drush cr
A deployment should also verify that the PHP-FPM user can load the Redis extension. Running php -m from the command line is not always sufficient because the command-line PHP configuration may differ from the PHP-FPM configuration used by the web server.
Moving The Right Cache Bins
Using Redis as Drupal’s default cache backend is a common starting point, but it should be tested rather than applied blindly. Most cache bins benefit from fast access, especially render, dynamic page cache, discovery, data, and configuration-related bins. A site with a large catalogue or complex Views configuration may see substantial improvement when repeated lookup data is kept out of the relational database.
Database storage can still be appropriate for some bins. A small site may gain little from moving every cache entry to a separate Redis service, particularly if Redis is running on a remote network. Keeping selected bins in the database can simplify troubleshooting and reduce the number of external dependencies. The correct arrangement depends on request volume, cache size, database performance, and the distance between application and Redis.
Sessions require special care. Storing Drupal sessions in Redis can reduce database writes for sites with many logged-in users, but it changes the failure behaviour of authentication. If Redis is restarted or evicts session keys, users may be logged out. For an Australian organisation handling customer accounts or personal information under the Privacy Act, document how session data is stored, protected, expired, and removed.
A cache backend should not be used to conceal inefficient code. Slow Views queries, unindexed fields, oversized images, excessive JavaScript, and expensive third-party API calls remain problems when a cache miss occurs. Redis improves the common cached path; it does not make an unoptimised request inexpensive.
Measuring Real Performance Improvements
Begin with a baseline before enabling Redis. Record page response time, time to first byte, PHP-FPM saturation, database CPU, database queries, cache hit ratio, and memory usage. Test anonymous and authenticated pages separately because Drupal’s Internal Page Cache usually benefits anonymous visitors more than logged-in users.
After enabling Redis, compare the same URLs under similar conditions. A command such as redis-cli INFO stats can show keyspace hits and misses, while redis-cli INFO memory reports memory consumption and eviction activity. Redis monitoring should also cover connected clients, blocked clients, rejected connections, uptime, and latency. A high hit count is useful, but it does not prove that visitors are receiving fast pages if PHP rendering or network delivery remains slow.
Load testing should include cache warm-up and cache invalidation. A site can appear extremely fast when a single page is repeatedly requested from a warm cache, then perform poorly when a large content import clears related tags. Test editorial publishing, menu updates, user login, search, and scheduled cron tasks. This is especially relevant for Australian retail websites preparing for Boxing Day campaigns or end-of-financial-year promotions, when traffic and catalogue changes can increase together.
Check the application logs after deployment. Connection failures may cause Drupal to fall back to database caching or produce service errors, depending on the configuration. A Redis restart should have a documented recovery process, and deployments should avoid flushing the entire cache unless there is a clear reason. Selective invalidation preserves useful warm data and reduces the spike of simultaneous cache rebuilds.
Avoiding Common Redis Deployment Problems
The most frequent mistake is treating Redis as unlimited memory. Large render arrays, oversized configuration objects, and unbounded custom data can fill the instance quickly. Set a realistic memory limit, inspect the largest keys, and watch eviction counts. If Redis evicts frequently, increase memory, reduce the data stored there, or revise the eviction policy after confirming which bins are disposable.
Another problem is running Redis and PHP on overloaded infrastructure. A low-latency cache does not compensate for CPU contention, insufficient RAM, slow disks used for persistence, or too many PHP-FPM workers. Redis persistence settings should reflect its role. A disposable cache may not need the same durability as a queue or database, but abrupt restarts should still be considered in the recovery plan.
Cache invalidation errors often appear after module updates or custom development. Drupal’s cache tags normally handle content changes, but custom code that writes directly to Redis or bypasses Drupal’s cache API can leave stale values behind. Custom modules should use Drupal cache bins, cache tags, cache contexts, and cache max-age rather than inventing parallel key-management rules.
Local hosting arrangements deserve attention. A Perth site serving users around Western Australia may benefit from a nearby application region, while a national organisation may choose Sydney or Melbourne for staff, cloud availability, and support arrangements. Content delivery networks can reduce static asset latency across Australia, but they do not replace a local Redis connection between the Drupal application and its cache service.
Comparing Cache Backends And Operating Choices
The best backend depends on the site’s scale, hosting model, and operational requirements. Redis usually offers the strongest performance for high-traffic Drupal installations, while database caching remains easier to deploy for modest projects. A reverse proxy or CDN works at a different layer: it can serve complete responses or static assets before PHP runs, whereas Redis accelerates Drupal’s internal application work.
The following comparison helps place Redis within a broader caching architecture:
| Option | Best suited to | Main advantage | Main limitation |
|---|---|---|---|
| Database cache tables | Small or simple Drupal sites | No extra service to operate | Adds database reads and writes |
| Redis cache backend | Busy sites with repeated dynamic work | Fast in-memory cache access and lower database load | Requires memory planning, monitoring, and secure connectivity |
| Memcached | Straightforward disposable object caching | Simple and fast key-value storage | Fewer data-management features and limited durability options |
| Drupal Internal Page Cache | Anonymous visitors receiving cacheable pages | Avoids rebuilding complete pages in PHP | Limited benefit for highly personalised pages |
| Dynamic Page Cache | Sites with varied page contexts | Reuses renderable page portions safely | Requires correct cache contexts and invalidation |
| CDN or reverse proxy | Static assets and cacheable public responses | Serves content close to visitors and reduces origin traffic | Does not solve slow uncached Drupal operations |
A resilient Drupal platform often combines these layers. Redis handles internal cache bins, Drupal’s page caches handle reusable responses, and a CDN serves images, CSS, JavaScript, and suitable public pages. Database indexes, image optimisation, PHP OPcache, and sensible cron scheduling complete the arrangement.
Redis delivers the greatest value when it is close to the application, protected from public access, sized from measured usage, and monitored after release. With those safeguards in place, Drupal can spend less time repeating cache work and more time handling the requests that require genuine content and business logic.