WordPress
Redis
Redis is an in-memory data store that WordPress sites commonly use as a persistent object cache. It is the usual choice when a host offers one because it can survive restarts and supports more than plain strings.
How it is measured
The WordPress side is a drop-in at wp-content/object-cache.php, installed by a plugin such as Redis Object Cache, plus constants in wp-config.php like WP_REDIS_HOST, WP_REDIS_PREFIX, and WP_REDIS_DATABASE. The plugin's status page and wp redis status report whether it is connected.
Measure it with redis-cli INFO stats: keyspace_hits and keyspace_misses give a hit rate, evicted_keys shows memory pressure against maxmemory, and used_memory_human gives the size.
Worked example
A membership site with 5,000 active users sets maxmemory to 100 MB with maxmemory-policy allkeys-lru. After a week, INFO shows 41 million hits, 3.2 million misses, and 880,000 evicted keys. The hit rate is 93 percent, but evictions mean useful data is leaving.
Raising maxmemory to 256 MB drops evictions to under 20,000 a week. The member dashboard page falls from 1.6 seconds to 0.9.
How it differs
Redis can persist data to disk and hold structures like sets, while Memcached is simpler and keeps only strings in memory. In WordPress both sit behind the object cache API, so your plugins call the same functions either way. Redis is the cache service, and object cache is the role it plays.
Common errors
Not setting WP_REDIS_PREFIX when several sites share one instance. Running with no maxmemory, so Redis eats the server's RAM. Using the same database number for two sites and flushing both. Exposing port 6379 without a password. Assuming Redis speeds up pages that a page cache already serves.
In practice
Run INFO stats and write down the hit rate and evicted_keys for a week. Set maxmemory with an allkeys-lru policy. Give each site its own prefix. Bind Redis to localhost and require a password.