Redis Performance Tuning

Redis runs fast out of the box, yet careless commands and oversized data can slow it down. Performance tuning means finding slow spots and removing them. Small changes in command choice, data design, and settings often deliver the biggest gains.

The Highway Analogy

Redis handles commands one at a time, like a single-lane highway. Small cars pass quickly. One huge truck slows every car behind it. Tuning means keeping trucks off the road and keeping traffic flowing.

  Fast lane (Redis processes one command at a time)

  ► ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪   smooth, many quick commands
  ► ▪ ▪ ▪ ▓▓▓▓▓▓▓▓▓▓ ▪ ▪   one slow command blocks the rest
                   ▲
             KEYS * on a huge database

Step 1: Find Slow Commands with SLOWLOG

Redis records commands that exceed a time limit. The limit is measured in microseconds.

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 10000
OK
127.0.0.1:6379> SLOWLOG GET 2
1) 1) (integer) 14
   2) (integer) 1718000000
   3) (integer) 48210
   4) 1) "KEYS"
      2) "*"

The third value shows the run time in microseconds. This example shows a KEYS command that took about 48 milliseconds.

Step 2: Avoid Heavy Commands

Risky Command          Safer Choice
─────────────────────  ───────────────────────────
KEYS pattern           SCAN with a small COUNT
SMEMBERS on big Set    SSCAN
HGETALL on big Hash    HSCAN or HMGET for chosen fields
LRANGE 0 -1 on a long List    LRANGE with small ranges
DEL on a huge key      UNLINK
FLUSHALL               FLUSHALL ASYNC

Step 3: Shrink Big Keys

A big key holds a very large value, such as a Hash with millions of fields. Big keys slow replication, deletion, and snapshots. Find them with the built-in scanner.

$ redis-cli --bigkeys
Biggest hash found "orders:all" has 2400000 fields

Split big keys into smaller ones, for example orders:2026-06 and orders:2026-07.

Step 4: Cut Network Waiting

• Batch commands with pipelining.
• Use MGET and MSET for many keys at once.
• Reuse connections through a connection pool instead of opening a new one per request.
• Place the app and Redis in the same region or data center.

Step 5: Measure Latency

$ redis-cli --latency
min: 0, max: 2, avg: 0.18 (1432 samples)

$ redis-cli --intrinsic-latency 5
Max latency so far: 41 microseconds.

The first test measures round-trip time to the server. The second test measures delay caused by the host machine itself.

Step 6: Review Server Settings

Setting                       Advice
────────────────────────────  ──────────────────────────────────────────
maxmemory                     Always set it with a suitable policy
save and appendfsync          Choose the lightest option your data allows
io-threads                    Raise to 2-4 on busy multi-core hosts
Transparent Huge Pages (OS)   Turn off to prevent latency spikes
Swap (OS)                     Keep Redis out of swap

Practical Example – Fixing a Slow Dashboard

Symptom: The dashboard hangs for 2 seconds every minute.

Check 1:  SLOWLOG shows HGETALL on "stats:all" taking 1.8 seconds.
Check 2:  redis-cli --bigkeys shows "stats:all" holds 3 million fields.

Fix:      Split data into one Hash per day.
          Read only the fields the dashboard needs with HMGET.

Result:   Longest command drops to 3 milliseconds.

Key Points

• SLOWLOG reveals commands that block the single processing lane.
• Replace KEYS, SMEMBERS, and HGETALL on large data with their scan versions.
• Split big keys into smaller keys.
• Pipelining and connection pools reduce network cost.
• Test latency before and after every change.