Drupal Redis Integration Guide for Better Performance

High-traffic Drupal sites rely on fast database access, efficient caching, and stable session handling. When a site begins to slow under repeated anonymous page views, frequent authenticated activity, or heavy editorial workflows, Redis can provide a meaningful performance boost by moving selected cache operations into memory.

Why Redis Improves Drupal Performance

Drupal uses cache bins to store rendered pages, configuration data, discovery information, routes, entities, and other frequently requested items. By default, many of these cache records may be stored in the database. On small sites, that approach is often acceptable. On larger sites, database-backed caching can become a bottleneck because the database must handle both content queries and cache read-write operations.

Redis is an in-memory key-value store designed for speed. Since memory access is much faster than disk-based storage, Redis can reduce database load and improve response times. It is especially useful for sites with high anonymous traffic, many authenticated users, complex views, or frequent cache reads.

However, Redis should be treated as part of a broader performance strategy. It works best alongside optimized database queries, properly configured reverse proxies, efficient themes, PHP OPcache, and a tuned hosting environment.

Core Requirements

Before integrating Redis with Drupal, the technical team should confirm that the environment supports the required components. A typical setup includes:

• Drupal 9, 10, or 11, depending on the project version.
• Redis server installed locally or available through a managed hosting service.
• PHP Redis extension, often named phpredis.
• Drupal Redis module, installed through Composer.
• Command-line access for cache rebuilds and configuration testing.

In hosted environments, Redis may already be available as a service. In self-managed infrastructure, Redis can be installed through the operating system package manager or deployed as a container. Security should be considered early, especially when Redis runs on a network-accessible host.

Installing the Drupal Redis Module

The recommended method is Composer. A development team usually installs the module with the following command:

composer require drupal/redis

After installation, the module can be enabled with Drush:

drush en redis -y

Although Drupal’s administrative interface can also enable modules, Drush is usually preferred on production-oriented workflows because it is repeatable and easier to include in deployment scripts.

Configuring Redis in settings.php

The main integration is completed in the site’s settings.php file. The configuration tells Drupal where Redis is located and which cache backend should use it. A common example looks like this:

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;

$settings['cache']['default'] = 'cache.backend.redis';

If Redis requires authentication, a password entry may also be added:

$settings['redis.connection']['password'] = 'strong-password-here';

For production sites, sensitive values should not be committed to version control. Many teams place passwords and host values in environment-specific settings files or inject them through environment variables.

Choosing Cache Bins Carefully

The simplest configuration sends all default cache operations to Redis. This approach is often effective, but advanced Drupal sites may benefit from more selective cache bin mapping. Some bins are excellent Redis candidates, while others may require caution depending on site behavior.

• Render cache: Often a strong Redis candidate because rendered output is frequently reused.
• Dynamic page cache: Useful for improving response times for partially cached pages.
• Discovery cache: Helpful for reducing repeated lookups of plugins, routes, and system definitions.
• Bootstrap cache: Can improve early request handling.

Some teams keep specific cache bins in the database when they need persistence across Redis restarts. Others configure Redis persistence with RDB or AOF snapshots. The choice depends on tolerance for cache loss, recovery expectations, and hosting constraints.

Clearing and Testing the Cache

After configuration changes, the team should rebuild Drupal caches:

drush cr

Then Redis activity can be checked with the Redis command-line tool:

redis-cli monitor

This command shows live Redis operations and can confirm that Drupal is writing cache entries. For less noisy inspection, administrators may use:

redis-cli info

The output includes memory usage, connected clients, key counts, and other metrics. If Redis remains idle after Drupal cache rebuilds and page requests, the configuration may not be loading correctly.

Performance Validation

A successful Redis integration should be measured rather than assumed. The site team should compare performance before and after deployment using real metrics such as:

• Average response time for uncached and cached pages.
• Database query volume during peak traffic.
• Cache hit ratio inside Redis.
• Memory usage and eviction behavior.
• PHP worker utilization under load.

Tools such as New Relic, Blackfire, Grafana, or hosting dashboards can help identify whether Redis is reducing database pressure. Load testing should be performed carefully, preferably against a staging environment that resembles production.

Memory and Eviction Settings

Redis stores data in memory, so memory planning is essential. If Redis reaches its memory limit, it may evict keys depending on its configured policy. For Drupal cache use cases, an eviction policy such as allkeys-lru or volatile-lru may be appropriate, but the right setting depends on the broader Redis deployment.

The team should avoid using the same Redis database for unrelated applications unless namespacing, database separation, or separate Redis instances are clearly defined. Shared Redis usage can create conflicts, memory pressure, or unpredictable evictions.

Security Considerations

Redis should not be exposed directly to the public internet. Best practice is to bind Redis to localhost or a private network interface. Authentication should be enabled when Redis is reachable over a network, and firewall rules should restrict access to trusted application servers only.

Transport encryption may also be required in regulated environments. Managed Redis providers often support encrypted connections, while self-managed installations may need additional configuration through stunnel, TLS-enabled Redis, or private networking.

Common Pitfalls

• Missing PHP extension: The Drupal module may be installed, but Redis will not work correctly without a supported PHP client.
• Incorrect settings file: Multisite projects may have several settings files, and the wrong one may be edited.
• No cache rebuild: Drupal must rebuild caches after configuration changes.
• Insufficient memory: Redis can become unstable or ineffective if memory limits are too low.
• Unverified results: Teams sometimes assume Redis is active without checking Redis metrics or Drupal behavior.

Best Practices for Production

For production deployments, Redis should be integrated through a controlled release process. The team should test the setup in staging, monitor logs during rollout, and have a rollback plan. Redis service restarts should be coordinated with expected cache rebuild behavior, because a cold cache can temporarily increase database load.

Managed hosting platforms may offer built-in Redis integration, which reduces operational complexity. In custom infrastructure, the operations team should define backup, persistence, monitoring, memory limits, and alerting policies. The best configuration is one that improves performance without introducing hidden reliability risks.

FAQ

Does every Drupal site need Redis?

No. Small or low-traffic sites may perform well with database caching. Redis is most useful when database load, authenticated traffic, or cache volume becomes significant.

Can Redis replace Drupal page caching?

No. Redis supports Drupal’s cache backend, but it does not replace page caching, Dynamic Page Cache, a CDN, or a reverse proxy. It complements those layers.

Is Redis safe for production?

Yes, when configured properly. It should run on a private network, use authentication when needed, and have memory limits, monitoring, and alerting in place.

What happens if Redis is cleared or restarted?

Most Drupal cache data can be rebuilt. However, a cold cache may temporarily increase database and PHP workload until frequently used items are regenerated.

How can a team confirm that Drupal is using Redis?

The team can inspect Redis with redis-cli monitor or redis-cli info, review Drupal configuration, and verify that cache keys are created during page requests and cache rebuilds.