10 Essential Redis Tips to Boost Performance and Reliability

1. Stop Using KEYS *

The KEYS * command scans the entire keyspace with O(n) complexity, which can block the server for large datasets. Use SCAN instead; it iterates incrementally via a cursor and can be paused or resumed.

for key in 'keys *':
    doAllTheThings()

2. Identify Performance Bottlenecks with INFO commandstats

Redis provides per‑command statistics via INFO commandstats. The output includes call count, total microseconds, and average latency for each command.

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

Run CONFIG RESETSTAT to clear the counters and obtain a fresh snapshot.

3. Treat redis-benchmark Results as Reference Only

redis-benchmark

measures raw GET/SET throughput, which is useful for sanity checks but does not reflect real‑world workloads. Consider the following factors when interpreting results:

Client runtime limitations

Redis version parity between test and production

Similarity of test environment to the production environment

Use the benchmark to verify that the server is not in an abnormal state, but never rely on it as a full‑scale load test.

4. Prefer Hashes Over Multiple Keys

Storing related fields as separate keys (e.g., user:first_name, user:last_name) wastes memory and increases management overhead. A single hash consolidates these fields under one key.

127.0.0.1:6379> HSET user first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET user last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET user address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL user
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"

5. Set Expiration (TTL) on Keys

Whenever possible, assign a timeout to keys using EXPIRE or by specifying an expiration when creating the key (e.g., SETEX). This is ideal for temporary data such as OAuth tokens, allowing Redis to automatically purge expired entries without manual scanning.

6. Choose the Right Eviction Policy

If you use expirations, the volatile‑lru policy evicts the least recently used keys with a TTL. For cache‑like data without TTL, consider allkeys‑lru . Select the policy that matches your usage pattern.

7. Guard Critical Writes with Try/Except

Most Redis clients employ a fire‑and‑forget approach. Wrap important write operations in a try/except (or equivalent error‑handling) block to confirm that the command succeeded and to handle potential network or server errors.

8. Distribute Load Across Multiple Instances

Do not overload a single Redis instance. Since Redis 3.0, clustering enables sharding by key range with master/replica pairs. If clustering is unavailable, use logical namespaces or run multiple independent instances to spread the keyspace.

9. More CPU Cores Do Not Speed Up a Single Instance

Redis runs as a single‑threaded process; even with persistence enabled it utilizes at most two CPU cores. Running multiple instances on the same host is only advisable for isolation in testing environments.

10. Ensure High Availability with Sentinel

Redis Sentinel monitors master instances, performs automatic failover, and provides notification services. Deploy Sentinel to maintain continuous availability for production workloads.

Source: http://objectrocket.com/blog/how-to/10-quick-tips-about-redis/