Performance Tuning Interview Questions

Pipelining batches commands on one connection so you pay one RTT for N commands. It is not atomicity; MULTI/EXEC is. Unbounded pipelines can grow client buffers. Size batches, for example 100 to 1000, and measure.

Big keys dominate p99 because the single thread copies megabytes for one GET or HGETALL. redis-cli --bigkeys and MEMORY USAGE find them. Split HASH fields or use HSCAN instead of full dumps.

SLOWLOG records commands slower than slowlog-log-slower-than, in microseconds. SLOWLOG GET is the first stop before guessing. A slow KEYS or HGETALL of a big hash shows up here.

UNLINK and lazyfree-lazy-eviction free memory in a background thread so DEL of a big key does not stall. lazyfree-lazy-expire similarly. Turning these on is a standard tuning step after a big-key incident.

Unix socket via unixsocket beats TCP loopback for local clients: no TCP overhead. Use it for sidecars on the same host. Remote clients still need TCP and should pipeline.

io-threads in Redis 6+ parallelize network reads and writes, not command execution. Raising io-threads will not make INCR scale across cores. It helps when you are network-bound with many small commands.

client-output-buffer-limit for replica and pubsub protect the instance from a slow replica or subscriber. Hitting the limit drops that client. If replicas flap, the buffer may be too small for a burst, or the replica is too slow.

maxclients and connection storms: each client has buffers. A burst of short-lived connections from a bad pool is slower than a few pipelined persistent connections. Tune timeouts and pools before adding hardware.

LATENCY DOCTOR and LATENCY HISTORY explain forks, aof_fsync, and expiration cycles. It is more precise than a generic CPU graph. Run it during the incident, not after the child save finished.

Hash max listpack thresholds: tiny values in compact encoding are smaller; conversion to hashtable can make HGET slightly faster at huge size but RAM worse. Tune with the actual field count, not folklore.

Avoid KEYS in production; SCAN is incremental but still O(N) overall. Frequent full SCAN is a background DoS. Keep secondary indexes in a SET or STREAM instead of scanning.

Pipelining versus MGET: MGET is one command with many keys and is cross-slot unless they share a tag. A pipeline of GET works across slots with a cluster client that fans out. Know which your client uses.

expire cycle and hz: many keys expiring at once, an eviction storm, steal the thread. TTL jitter and lazyfree-lazy-expire help. Watch expired_keys in INFO stats.

Transparent huge pages plus fork equals latency spikes during BGSAVE. Disable THP on Redis hosts. This is still one of the most common Redis is slow every minute answers.

CPU pinning and NUMA: Redis command path is one thread plus optional io-threads. Give that thread a quiet core. Competing with noisy neighbors on a VM is not fixed by raising maxmemory.

Client-side caching TRACKING reduces GET traffic for hot keys but adds invalidation messages. Net win when read/write ratio is high. Measure redirected traffic; it can hurt chatty write workloads.

Protocol RESP3 versus RESP2, and disabling huge MONITOR sessions, matter before you tune data structures. TLS termination CPU can dominate before Redis CPU. Profile the client and the NIC, not only INFO commandstats.

commandstats in INFO: calls and usec per command. A surprising amount of time in HGETALL or SMEMBERS points to big keys. Fix the command shape before buying a bigger box.

Replica-serve-stale versus read-from-primary-only: extra GET load on the primary is a performance choice. Replicas help reads if the app tolerates lag. Misconfigured replica reads with WRITE commands will error.

Upgrade path for performance: Redis 7 io-threads, client-side caching, and sharded Pub/Sub may remove whole classes of work. Benchmark with redis-benchmark and your pipeline mix, not GET/SET only.