An object cache keeps the RESULT of work in memory so the next request does not repeat it. On a site that asks the database the same questions on every page, the effect is large. On a site whose pages are slow for other reasons, it is nothing.

When it helps

  • A CMS that loads dozens of settings rows on every request - WordPress asks for its options on every single page.
  • Menus, taxonomies, user metadata: small, repeated, identical.
  • Sessions, which otherwise become thousands of small files on disk.

When it does not

A page that is slow because of ONE query over a large table stays exactly as slow. The cache saves repeated work, not expensive work. Fix the query first; caching it only hides how bad it is until the cache is cold.

Set a memory limit and an eviction policy

maxmemory 256mb\nmaxmemory-policy allkeys-lru

Without maxmemory Redis grows until the machine has no memory left, and the kernel then kills something - often the database. allkeys-lru discards the least recently used key instead, which is what a cache should do.

Bind it to localhost

Redis has no authentication by default. A Redis reachable from the internet is an open door: it can be told to write files. Bind to 127.0.0.1 and require a password.
bind 127.0.0.1\nrequirepass a-long-random-string

Check it is actually being used

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

Hits far above misses means it is working. Misses dominating means keys are expiring too fast or being flushed by something on every request.

A page cache and an object cache are different things. A page cache serves a whole finished page and helps anonymous visitors; an object cache helps logged-in ones, whose pages cannot be shared.