A cache goes in, the page gets faster, and that is usually where the measurement stops. Redis has been counting every lookup since it started and will tell you what fraction of them found anything — which, on a cache keyed by something too specific, is routinely under 20%: all of the write cost and almost none of the benefit.
redis-cli INFO stats | grep keyspace
# keyspace_hits:2841077
# keyspace_misses:9330412 -> 23% of lookups found something
redis-cli INFO keyspace
# db0:keys=184220,expires=183991,avg_ttl=1780412
# before concluding anything about size
redis-cli INFO stats | grep evicted_keys
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'The counters are cumulative since the last restart, so the raw numbers describe the whole uptime; a ratio computed from two readings a minute apart is the one that describes now. expires against keys is the other line worth reading — a large gap means keys were written with no TTL and will sit there until something evicts them. A low hit rate is usually a key design problem rather than a capacity problem: a key containing a timestamp, a session id, or filter parameters in whatever order the query string happened to supply can only ever be read by the request that wrote it. Check evicted_keys first, though. If it is climbing, the instance is large enough on paper and is discarding entries under maxmemory regardless.