11. Performance Optimization

11.1 Pipeline — Batch Sending

🚀 Analogy: Normal mode is like "sending one package at a time," Pipeline is like "saving up a bunch of packages and sending them all at once" — reducing network round-trips.

# Normal mode: 10000 GETs = 10000 network round-trips
# Pipeline mode: 10000 GETs = 1 network round-trip

# Using Pipeline in redis-cli
# First prepare a commands.txt file:
SET key1 val1
SET key2 val2
SET key3 val3
GET key1
GET key2
GET key3

# Batch execute
cat commands.txt | redis-cli --pipe

# Python example (redis-py)
pipe = redis_client.pipeline(transaction=False)
for i in range(10000):
    pipe.set(f"key:{i}", f"value:{i}")
results = pipe.execute()  # Send all commands at once

All data transferred. Waiting for the last reply...
Last reply sent from server.
errors: 0, replies: 6

💡 Tip: Pipeline is not atomic, but it's 5-10x faster than sending commands one by one. Great for batch imports, batch queries, etc.

11.2 Slow Query Log

# Configure slow query threshold
CONFIG SET slowlog-log-slower-than 10000  # Log if over 10ms
CONFIG SET slowlog-max-len 128            # Keep at most 128 entries

# View slow query log
SLOWLOG GET 10

# View slow query count
SLOWLOG LEN

# Clear slow query log
SLOWLOG RESET

OK
OK
1) 1) (integer) 125
   2) (integer) 1704067200
   3) (integer) 15234
   4) 1) "KEYS"
      2) "*"
   5) "192.168.1.50:54321"
   6) ""
2) 1) (integer) 124
   2) (integer) 1704067150
   3) (integer) 52100
   4) 1) "SORT"
      2) "mylist"
      3) "LIMIT"
      4) "0"
      5) "10000"
   5) "192.168.1.50:54322"
   6) ""
(integer) 126
OK

11.3 Big Key Detection

Big Keys are Redis performance's hidden killers! A List containing 1 million elements can block the server for hundreds of milliseconds when deleted.

# Method 1: redis-cli big key scan (production-safe, non-blocking)
redis-cli --bigkeys

# Method 2: MEMORY USAGE to check single key memory usage
MEMORY USAGE user:1001

# Method 3: Use SCAN + TYPE + sub-commands to detect
# Scan and check each key's size
redis-cli --memkeys

# Method 4: View a single key's encoding and element count
OBJECT ENCODING user:1001
OBJECT HELP

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.
[00.00%] Biggest string found so far 'user:1001:name' with 5 bytes
[45.00%] Biggest hash found so far 'cache:product_all' with 50000 fields
[100.00%] Biggest list found so far 'queue:tasks' with 998765 items

-------- summary -------

Sampled 157432 keys in the keyspace!
Total key length in bytes is 4722960 (avg len 30.00)

Biggest string found 'session:token_xyz' has 524288 bytes
Biggest hash   found 'cache:product_all' has 50000 fields
Biggest list   found 'queue:tasks' has 998765 items
Biggest set    found 'users:online' has 125000 members
Biggest zset   found 'leaderboard:game1' has 200000 members

(integer) 80
"ziplist"

# Safely delete big keys (async deletion, non-blocking)
UNLINK big_key_name

# Or use UNLINK for batch deletion
UNLINK key1 key2 key3

# Configure lazy deletion thresholds
CONFIG SET lazyfree-lazy-expire yes
CONFIG SET lazyfree-lazy-server-del yes

⚠️ Note: Never use KEYS * in production! It scans all keys and blocks the server. Use SCAN instead.