Redis and Memcached

Redis and Memcached are in-memory stores that cache data so PHP does not repeat the same MySQL queries. WordPress can use either one as an object cache. Redis supports richer structures such as strings, hashes, lists, and sorted sets. Memcached is a simpler key-value slab and remains a solid choice for basic needs.

What each one is good for

Memcached is not obsolete. It stays simple and works fine for many sites. Redis tends to fit better with WooCommerce session plugins and anything that wants a hash instead of a single blob. On LogicWeb plans that include Redis, it is the intended object cache for WordPress. Object cache is not the same as page cache. Redis will not serve full HTML pages to anonymous visitors. LiteSpeed Cache handles that layer. Redis saves PHP from repeating SQL on requests that still miss or cannot be cached, such as cart, account, and wp-admin pages.

Bind address and maxmemory

Always bind Redis to localhost so the port is not open on the public interface. Use bind 127.0.0.1, and add ::1 only if you need IPv6 locally. Firewall the port anyway as a second layer. Memcached has the same risk on port 11211 if it listens on all interfaces. AUTH on localhost is still wise if you run untrusted PHP, because a plugin can reach port 6379 as easily as your drop-in can.

redis-cli info memory | head

Check used_memory_human and maxmemory in that output. Those two lines tell you whether Redis has room to grow. If maxmemory is 0, Redis can expand until the OOM killer stops it or stops MariaDB. Set a hard cap and an eviction policy such as allkeys-lru when you use Redis as a cache. Evictions are normal. Running out of memory is not.

Persistence, prefixes, and shared plans

RDB or AOF snapshots usually do not belong on a WordPress object cache. After a crash you would rebuild the cache from MySQL anyway. Turn persistence off unless you store sessions you truly cannot rebuild. A growing dump file can also fill the disk when AOF is left on a busy shop. Two WordPress sites that share one Redis instance without a key prefix will overwrite each other’s data. The drop-in has a prefix setting, so use a unique prefix per site. The same collision can happen with one Memcached slab and less visibility. Give each app its own instance or its own prefix, and leave enough free memory for MariaDB. On shared plans that offer Redis, we bind it for you. Do not open it to the world so staging can connect. Give staging its own cache or use a tunnel instead.