Redis Production & Operations

# Basic benchmark: 100K requests, 50 parallel connections, SET/GET
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50

# Benchmark specific commands
redis-benchmark -t set,get,incr,lpush,rpush -n 100000 -q

# Benchmark with pipelining (batching 16 commands per round-trip)
redis-benchmark -t set -n 100000 -P 16 -q

# Benchmark with specific data size (1KB values)
redis-benchmark -t set -n 100000 -d 1024 -q

# Sample output:
# SET: 112,359.55 requests per second
# GET: 118,483.41 requests per second
# INCR: 115,606.94 requests per second
# LPUSH: 114,025.09 requests per second
# With pipelining (P=16): ~800,000 requests per second

# ❌ DANGEROUS: blocks the server until all keys are scanned
KEYS user:*

# ✅ SAFE: cursor-based iteration, returns ~10 keys per call
# Start with cursor 0
SCAN 0 MATCH user:* COUNT 100

# Returns: next_cursor + batch of matching keys
# 1) "17920"          ← next cursor (0 means done)
# 2) 1) "user:42"
#    2) "user:108"
#    3) "user:7"

# Continue with returned cursor
SCAN 17920 MATCH user:* COUNT 100

# Keep going until cursor returns "0"
# Each call takes O(COUNT) time — doesn't block the server

# Same pattern for other data structures:
SSCAN myset 0 COUNT 100      # iterate set members
HSCAN myhash 0 COUNT 100     # iterate hash fields
ZSCAN myzset 0 COUNT 100     # iterate sorted set members

# Configure slowlog threshold (in microseconds)
# Log any command that takes longer than 10ms
CONFIG SET slowlog-log-slower-than 10000

# Keep the last 128 slow commands
CONFIG SET slowlog-max-len 128

# View the slowlog
SLOWLOG GET 10

# Sample output:
# 1) 1) (integer) 14            ← entry ID
#    2) (integer) 1693420800    ← Unix timestamp
#    3) (integer) 38102         ← execution time (μs) = 38ms
#    4) 1) "KEYS"               ← the command
#       2) "session:*"          ← the argument
#    5) "10.0.1.42:52340"       ← client address

# Reset the slowlog
SLOWLOG RESET

# Check how many entries are in the slowlog
SLOWLOG LEN

# Check current thresholds
CONFIG GET hash-max-ziplist-entries
CONFIG GET hash-max-ziplist-value
CONFIG GET list-max-ziplist-size
CONFIG GET set-max-intset-entries
CONFIG GET zset-max-ziplist-entries
CONFIG GET zset-max-ziplist-value

# Increase hash ziplist threshold (default: 128 entries, 64 bytes)
# If your hashes have 200 small fields, raising this saves memory
CONFIG SET hash-max-ziplist-entries 256
CONFIG SET hash-max-ziplist-value 128

# Trade-off: higher thresholds = less memory, but slower O(N) scans
# on the ziplist. Sweet spot is usually 128-512 entries.

# Redis 7.0+ uses listpack instead of ziplist (same concept, better impl)
CONFIG GET hash-max-listpack-entries
CONFIG GET hash-max-listpack-value

# Check memory usage of a specific key (Redis 4.0+)
MEMORY USAGE user:42
# (integer) 72    ← 72 bytes including key overhead

# Check memory usage with samples for aggregate types
MEMORY USAGE myhash SAMPLES 5
# Samples 5 random fields to estimate total memory

# Overall memory stats
INFO memory
# used_memory: 1,234,567,890        ← total bytes used
# used_memory_human: 1.15G          ← human-readable
# used_memory_rss: 1,400,000,000    ← RSS (actual OS allocation)
# mem_fragmentation_ratio: 1.13     ← RSS / used_memory
# used_memory_peak: 2,000,000,000   ← historical peak

# Memory fragmentation ratio:
#   < 1.0  → Redis is swapping (BAD — add more RAM)
#   1.0-1.5 → healthy
#   > 1.5  → significant fragmentation (consider restart)

# Memory doctor (Redis 4.0+)
MEMORY DOCTOR
# Returns advice about memory issues

# External tool: redis-rdb-tools (analyze RDB dump offline)
# pip install rdbtools
# rdb --command memory dump.rdb --bytes 128 -f memory.csv
# Generates CSV with key, type, encoding, size, num_elements

# Every key name is stored in memory. Shorter = less RAM.

# ❌ Verbose keys (wastes memory at scale)
user:profile:details:john.doe@example.com:settings:notifications
# ~60 bytes just for the key name × 10M users = 600MB wasted

# ✅ Compact keys (saves memory)
u:42:s:n
# ~8 bytes × 10M users = 80MB

# ✅ Balanced approach (readable + compact)
u:{id}:profile     instead of  user:profile:details:{email}
s:{id}:cart        instead of  shopping:cart:items:user:{id}
sess:{token}       instead of  session:auth:token:{full-uuid}

# Use hashes to group related data (1 key instead of 5)
# ❌ 5 separate keys per user:
SET u:42:name "John"
SET u:42:email "john@example.com"
SET u:42:age "30"
SET u:42:city "NYC"
SET u:42:role "admin"
# Overhead: 5 keys × ~50 bytes overhead each = 250 bytes

# ✅ 1 hash with 5 fields:
HSET u:42 name "John" email "john@example.com" age 30 city "NYC" role "admin"
# Overhead: 1 key × ~50 bytes + ziplist encoding = ~120 bytes
# Saves ~50% memory for small field counts

# Full info dump (all sections)
INFO

# Specific sections
INFO memory          # memory usage, fragmentation, peak
INFO stats           # ops/sec, hits/misses, connections
INFO replication     # master/replica status, lag
INFO clients         # connected clients, blocked clients
INFO keyspace        # keys per database, expires
INFO server          # version, uptime, config file
INFO persistence     # RDB/AOF status, last save time

# Single stat shortcut
INFO stats | grep instantaneous_ops_per_sec

# Formula:
hit_rate = keyspace_hits / (keyspace_hits + keyspace_misses) × 100

# Example from INFO stats:
keyspace_hits:   9,500,000
keyspace_misses:   500,000
hit_rate = 9,500,000 / 10,000,000 = 95%  ✅ Healthy

# What hit rates mean:
# >99%  → Excellent. Cache is highly effective.
# 95-99% → Good. Normal for most workloads.
# 80-95% → Concerning. Review TTLs, key patterns, eviction.
# <80%  → Bad. Cache is not protecting the database.
#          Possible causes:
#          - TTLs too short (keys expire before reuse)
#          - Working set larger than maxmemory (evictions)
#          - Cold start (cache not yet warmed)
#          - Wrong data being cached (cache what's read often)

# Monitor hit rate over time, not as a snapshot.
# A drop from 98% to 85% over an hour = investigate immediately.

# Enable latency monitoring (threshold in ms)
CONFIG SET latency-monitor-threshold 5

# View latency history for specific events
LATENCY HISTORY command
# Returns timestamped latency samples:
# 1) 1) (integer) 1693420800    ← timestamp
#    2) (integer) 12            ← latency in ms

# View latest latency for all event types
LATENCY LATEST
# 1) 1) "command"               ← event type
#    2) (integer) 1693420800    ← last occurrence
#    3) (integer) 12            ← latest latency (ms)
#    4) (integer) 38            ← all-time max latency (ms)

# Reset latency data
LATENCY RESET

# Built-in latency diagnostic
redis-cli --latency           # continuous ping test
redis-cli --latency-history   # latency over time (15s intervals)
redis-cli --latency-dist      # latency distribution (spectrum)

# Intrinsic latency test (measures system, not Redis)
redis-cli --intrinsic-latency 5   # test for 5 seconds

Q: Does the data fit in RAM?
  NO  → Use a disk-based database (PostgreSQL, MongoDB)
  YES ↓

Q: Do you need complex queries (joins, aggregations, filters)?
  YES → Use PostgreSQL/MongoDB. Cache hot results in Redis.
  NO  ↓

Q: Do you need strong consistency (zero data loss)?
  YES → Use PostgreSQL with synchronous replication, or etcd.
        Redis can still be a cache layer in front.
  NO  ↓

Q: What's the access pattern?
  Key-value lookups     → Redis (Strings, Hashes)
  Ranked data           → Redis (Sorted Sets)
  Queue / task system   → Redis (Lists, Streams) or Kafka for scale
  Pub/Sub messaging     → Redis Pub/Sub (small scale) or Kafka (large scale)
  Session storage       → Redis (Strings with TTL)
  Rate limiting         → Redis (INCR + EXPIRE)
  Real-time analytics   → Redis (HyperLogLog, Bitmaps)

Rule of thumb: Redis is best as a cache, session store, or
real-time data layer — not as a primary database.

# Memory
maxmemory 12gb
maxmemory-policy allkeys-lru

# Persistence (both RDB + AOF for safety)
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

# Security
requirepass your-strong-password-here
bind 127.0.0.1 10.0.1.0
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""
rename-command DEBUG ""

# Connections
timeout 300
tcp-keepalive 60
maxclients 5000

# Slow log
slowlog-log-slower-than 5000
slowlog-max-len 256

# Latency monitoring
latency-monitor-threshold 5

# Replication safety
min-replicas-to-write 1
min-replicas-max-lag 10