11 Proven Ways to Keep Redis Lightning‑Fast and Avoid Latency

When Redis is chosen as a data store or cache for its impressive performance (up to 100k QPS per node), latency issues can still arise. To ensure Redis continuously delivers high performance, this article summarizes eleven optimization suggestions.

2. Optimization Suggestions

2.1 Avoid Large Keys

Large keys consume excessive memory and increase latency because Redis processes requests in a single thread. Deleting or reading a large key adds overhead in memory allocation, release, and network transmission, causing request queuing.

If large keys cannot be avoided, split them into multiple smaller keys.

2.2 Avoid Overly Complex Commands

Redis uses a single‑threaded model; complex commands such as SORT, SINTER, SINTERSTORE, ZUNIONSTORE, and ZINTERSTORE consume significant CPU time and block other requests. It is recommended to perform aggregation logic on the client side.

2.3 DEL Command Time‑Complexity

While DEL on a string key is O(1), deleting List/Hash/Set/ZSet keys is O(N) where N is the number of elements, because each element’s memory must be reclaimed in the main thread.

List: Repeatedly call LPOP / RPOP until empty.

Hash/Set/ZSet: Use HSCAN / SSCAN / SCAN to iterate elements, then delete each with HDEL / SREM / ZREM.

2.4 Use Lazy Free Mechanism

Enable lazy freeing (available from Redis 4.0) so that memory release for large keys occurs in a background thread, minimizing impact on the main thread.

# Use lazy free for memory eviction
lazyfree-lazy-eviction yes
# Use lazy free for key expiration
lazyfree-lazy-expire yes
# Use lazy free for server‑side deletions
lazyfree-lazy-server-del yes

2.5 Beware of O(N) Commands

Even when avoiding complex commands, O(N) operations can still cause latency if N is large. Avoid commands like LRANGE key 0 -1, HGETALL, SMEMBERS, and ZRANGE key 0 -1 on massive collections.

Best practice:

First query the collection size (e.g., LLEN, HLEN, SCARD, ZCARD).

If the size is small, fetch all data at once.

If the size is large, fetch data in batches using LRANGE, HSCAN, SSCAN, or ZSCAN.

2.6 Use Batch Commands

When operating on multiple keys, use batch commands to reduce network round‑trips.

For String/Hash, replace GET/SET with MGET/MSET and HGET/HSET with HMGET/HMSET.

For other types, employ Redis pipelines.

Example of a Spring Boot service using pipeline:

@Service
public class RedisPipeliningService {
    private final StringRedisTemplate stringRedisTemplate;
    public RedisPipeliningService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }
    public List<Object> pipe() {
        List<Object> results = stringRedisTemplate.executePipelined(connection -> {
            StringRedisConnection stringRedisConn = (StringRedisConnection) connection;
            for (int i = 0; i < 10; i++) {
                stringRedisConn.rPush("i" + i, String.valueOf(i));
            }
            return null;
        });
        return results;
    }
}

2.7 Avoid Simultaneous Key Expiration

Mass expirations can cause a “snowball” effect, blocking the main thread. Add a random offset to each key’s TTL to spread expirations over time.

2.8 Use Persistent Connections and Proper Pooling

Prefer long‑living connections over short‑lived ones to avoid TCP handshake overhead. Configure a connection pool with sensible limits and release idle connections promptly.

spring:
  data:
    redis:
      host: localhost
      port: 6379
      password: xxxooo
      connect-timeout: 10000
      timeout: 10000
      lettuce:
        pool:
          max-wait: -1
          max-active: 8
          max-idle: 8
          min-idle: 8

2.9 Use Only DB 0

Redis offers 16 logical databases, but using only DB 0 reduces SELECT overhead, simplifies architecture, and eases migration to Redis Cluster, which only supports DB 0.

2.10 Read‑Write Separation and Sharding

For read‑heavy workloads, deploy replica nodes and enable read‑write separation. For write‑heavy workloads, use a sharded cluster to distribute write pressure.

2.11 AOF Persistence Strategy

If data loss is acceptable, disable AOF to avoid disk‑write overhead. If AOF is required, set appendfsync everysec and let background threads handle disk flushing.

These eleven recommendations together form a comprehensive checklist for maintaining Redis’s high performance and stability in production systems.