Redis Tutorial 0/42 lessons ~6 min read Lesson 37

    Performance Tuning

    Redis performance tuning starts with pipelining, connection pooling, right-sized values, and eliminating slow commands — not buying bigger hardware first.

    Course progress0%
    Focus
    10 guided sections
    Practice signal
    Examples included
    Career prep
    Interview Q&A included

    Introduction

    Redis performance tuning starts with pipelining, connection pooling, right-sized values, and eliminating slow commands — not buying bigger hardware first. Default configs target dev laptops; production needs lazyfree, UNLINK, disabled THP, and co-located AZ placement.

    Profile with redis-benchmark only as sanity check — real workloads need application-level tracing with realistic value sizes and concurrent clients.

    Target p99 latency not average — one KEYS command spikes p99 for everyone.

    Understanding the topic

    Key concepts

    • Pipelining — batch RTT.
    • Connection pool max-active sizing.
    • UNLINK async delete vs blocking DEL.
    • lazyfree-lazy-user-del large key free.
    • Disable transparent huge pages Linux.
    • I/O threads help read/write not command CPU.

    Step-by-step explanation

    1. Measure baseline ops/sec and p99 latency.
    2. Identify RTT-bound vs CPU-bound paths.
    3. Apply pipeline/MGET to RTT issues.
    4. Replace DEL with UNLINK on big keys.
    5. Tune pool and co-locate network.
    6. Re-measure under load test.

    Syntax reference

    Common commands

    • UNLINK non-blocking delete large keys.
    • activedefrag when mem_fragmentation_ratio high.
    • LATENCY DOCTOR first tuning step.
    bash
    CONFIG SET lazyfree-lazy-user-del yes
    CONFIG SET activedefrag yes
    UNLINK big:hash:key
    INFO stats | grep instantaneous_ops
    LATENCY DOCTOR

    Informative example

    Enable lazy free and measure before/after large hash delete:

    bash
    redis-cli CONFIG SET lazyfree-lazy-user-del yes
    redis-cli DEBUG SLEEP 0
    # Before: time redis-cli DEL huge:hash
    # After: time redis-cli UNLINK huge:hash
    redis-cli INFO stats | grep lazyfree_pending_objects

    Spring: configure Lettuce pool max-active ~2× expected concurrent Redis users per pod.

    Real-world use

    Real-world use cases

    • API p99 SLA breach on cache layer.
    • Bulk delete migration without latency spike.
    • Flash traffic event capacity planning.
    • Reduce ElastiCache node size after optimization.
    • Post-deploy regression detection.

    Best practices

    • Pipeline all batch read paths.
    • Pool size from concurrency not guess.
    • UNLINK not DEL for >1KB aggregates.
    • Same AZ app and Redis.
    • Disable THP; set overcommit_memory.
    • Alert on slowlog growth.

    Common mistakes

    • Benchmark only SET GET 10 byte locally.
    • Pool max-active=1 on high traffic pod.
    • DEL million-field hash at peak.
    • More Redis CPU without fixing hot key.

    Advanced interview questions

    Q1BeginnerFirst Redis perf optimization?
    Pipeline batch commands to cut RTT.
    Q2BeginnerUNLINK vs DEL?
    UNLINK frees memory in background thread; DEL blocks event loop on large keys.
    Q3Intermediatelazyfree purpose?
    Async freeing of large values avoids latency spikes.
    Q4IntermediateWhy disable THP?
    Redis documentation — THP increases memory and latency issues.
    Q5AdvancedTune Spring Lettuce pool?
    Measure concurrent threads needing Redis; max-active ~2×; max-idle; timeout; validate under load test.

    Summary

    Pipeline and pool sizing — first wins.

    Ready to mark this lesson complete?Track your journey across the entire course.