WordPress + Redis Object Cache: Optimized Configs for Localhost, Docker, and ElastiCache

Redis is fantastic for WordPress—but its defaults are meant for a datastore, not a high-churn object cache. This guide shows you the exact Redis settings for localhost, Docker, and Amazon ElastiCache so you get a memory-bounded, low-latency cache with smart eviction and stable performance.

Table of Contents

Using Redis as a cache for WordPress (via the Redis Object Cache plugin) is a great way to cut database load and speed up page generation. Two things determine how well it works: where Redis runs (same host, Docker, or a managed service like Amazon ElastiCache for Redis) and the fact that Redis’s default configuration is not tuned for WordPress caching.

Out of the box, Redis ships with disk persistence enabled, no memory ceiling (maxmemory 0), and a noeviction policy—sensible for a datastore, but sub‑optimal for a high‑churn object cache. For WordPress you want an ephemeral, memory‑bounded cache with an allkeys-* eviction policy, active defragmentation, and lazy frees enabled.

Why the defaults aren’t ideal for WordPress

  • maxmemory is unset → the OS may OOM‑kill Redis under pressure.
  • maxmemory-policy noeviction → writes can fail at high memory instead of evicting cold keys.
  • Persistence is enabled → unnecessary disk I/O and longer restarts for a cache‑only role.
  • Active defragmentation is off → RSS can bloat long after traffic subsides.

This guide gives production‑ready settings for each deployment scenario, with copy‑pasteable snippets, and a short checklist to verify things are working.


TL;DR (Quick Recipe)

  • Treat Redis as ephemeral cache (no disk durability).
  • Set a memory ceiling and an eviction policy: maxmemory + allkeys-lfu (or allkeys-lru).
  • Turn on active defragmentation and lazyfree to stabilize memory.
  • Prefer phpredis client with persistent connections from PHP-FPM.
  • Give objects a sane TTL (1–24h) and a unique key prefix per site.
  • Monitor: redis-cli --stat, INFO, SLOWLOG, latency doctor.

Baseline: Redis as a WordPress Cache (applies everywhere)

Use these baseline settings whether Redis is local, containerized, or managed:

Key Redis settings

Choose maxmemory: On a dedicated Redis host, start with ~50–70% of RAM. On a shared web server, start smaller (e.g., 512MB–1GB) and watch evictions and OS memory pressure.

WordPress plugin (typical) wp-config.php additions

Prefixing: Use a unique WP_CACHE_KEY_SALT (or WP_REDIS_PREFIX) per site (e.g., domain name) to avoid key collisions in shared Redis.


Scenario A — Redis on the Web Server (localhost)

Best for: single server or small clusters where latency should be minimal and ops are simple.

Advantages

  • Lowest latency (UNIX socket possible)
  • Easiest to operate

How to configure

  1. Install Redis from your distro or a trusted package (prefer 7.x).
  2. Drop the baseline redis.conf above into /etc/redis/redis.conf.
  3. (Optional) Use a UNIX socket for lower overhead:
  4. Set maxmemory to a safe ceiling for your host.
  5. Restart Redis and point WordPress to the socket or 127.0.0.1:6379.

WordPress config example (UNIX socket)

Verification

  • redis-cli -s /var/run/redis/redis.sock INFO memory (or -h 127.0.0.1)
  • Ensure evicted_keys rises slowly once used_memory nears maxmemory.
  • Watch mem_fragmentation_ratio and run MEMORY PURGE during a maintenance window if fragmentation climbs.

Scenario B — Redis in Docker

Best for: containerized stacks (Docker Compose, Swarm, or K8s) that isolate services.

Advantages

  • Easy, reproducible deployments
  • Clean separation between app and cache

docker-compose.yml (example)

redis.conf

  • Use the baseline from above.
  • Set maxmemory appropriate to the container memory limit. If using Docker memory limits, ensure the container has enough headroom (Redis will not see host limits automatically).

WordPress config example

Kubernetes notes

  • Use a Deployment or StatefulSet for Redis with a ConfigMap for redis.conf.
  • Add resources requests/limits and a readinessProbe using redis-cli PING.

Scenario C — Amazon ElastiCache for Redis

Best for: high availability, managed patching, and easy scaling in AWS.

Topology

  • Replication group with 1 primary + ≥1 replica; enable Multi‑AZ and automatic failover.
  • Start with cluster mode disabled (single endpoint) unless you specifically need sharding, which requires cluster‑aware clients.

Parameters (Parameter Group)

  • Disable persistence: set save to empty ("").
  • Eviction: maxmemory-policy = allkeys-lfu (or allkeys-lru).
  • Memory stability: activedefrag = yes; enable lazyfree-* options if available.
  • Connection hygiene: tcp-keepalive = 60.
  • (ElastiCache sets maxmemory automatically per node size; choose instance classes with enough headroom.)

Security

  • Place Redis in a private subnet; restrict Security Groups to your app servers.
  • If in‑transit encryption is enabled, connect over TLS.

WordPress config examples

Failover

  • Point WordPress at the primary endpoint of the replication group. On failover, ElastiCache promotes a replica; the primary endpoint DNS updates automatically.

Verification

  • From an EC2 instance in the same VPC:
  • Watch evicted_keys, hit/miss rates, and latency.

Monitoring & Tuning Checklist

  1. Hit ratio: keyspace_hits vs keyspace_misses → adjust TTLs and cache coverage.
  2. Evictions: evicted_keys → steady non‑zero is normal at capacity; spikes suggest undersized maxmemory or too‑short TTLs.
  3. Fragmentation: mem_fragmentation_ratio → >2 for long periods? Enable activedefrag and occasionally run MEMORY PURGE during low traffic.
  4. Latency: latency doctor, SLOWLOG GET 128 → track slow commands and outliers.
  5. Connections: Prefer persistent connections; avoid connection churn.
  6. Backpressure: For Docker/K8s, ensure container/node memory limits exceed Redis maxmemory by 20–30% for overhead.

Troubleshooting

  • High misses, low evictions: Your cache may be under‑utilized—confirm the plugin is enabled, keys are being set, and TTLs aren’t too short.
  • Frequent evictions: Increase maxmemory (if you can), use allkeys-lfu, and consider lengthening TTLs for truly hot objects.
  • Memory keeps growing after traffic drops: Check fragmentation; run MEMORY PURGE or restart in a window.
  • Connection errors in ElastiCache: Verify Security Groups, subnet routing, and TLS/auth settings; increase timeouts slightly.
  • Shared Redis for multiple sites: Use unique WP_CACHE_KEY_SALT/prefix per site.

Appendix A — Baseline redis.conf (cache‑only)

Appendix B — Minimal docker-compose.yml

Appendix C — Example wp-config.php snippet


Need a hand?

If you share your RAM/CPU budget, traffic profile, and whether you’re on localhost, Docker, or ElastiCache, we can recommend an initial maxmemory, TTL strategy, and eviction policy tailored to your site(s).

Have a project or a problem?

Talk with a senior engineer for practical recommendations—no obligation.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Categories

Get a free consultation from Reliable Penguin

Submit the form—or for immediate service call 866-649-7984.