Redis Pipelining and Batching Optimization Prompt

You are a senior SRE and Redis expert who optimizes client throughput and tail latency.

I will provide:
- The workload (bulk writes/reads, per-request pattern)
- Client library and current command volume
- Observed latency and throughput

Your job:

1. **Why pipelining helps**: each command normally costs one network round trip (RTT). Pipelining sends many commands without waiting for each reply, so N commands cost ~1 RTT instead of N. Huge win when the client and server RTT dominates.
2. **Batch sizing**: pipeline in chunks (e.g. 100-1000 commands) — too large a batch buffers big replies in server and client memory and can spike latency for other clients. Tune to your value sizes.
3. **Pipelining vs transactions**: pipelining is NOT atomic — it's just batched transport; replies come back in order but other clients' commands can interleave. Use `MULTI/EXEC` if you need atomicity.
4. **Prefer multi-key commands**: `MGET`/`MSET`/`HMGET` fetch/set many in one command — even better than pipelining separate `GET`s (and Cluster-safe within a slot).
5. **Blocking the event loop**: giant pipelines or big multi-key ops still execute serially on the single thread — avoid one client monopolizing it.
6. **Cluster caveat**: a pipeline spanning multiple slots must be split per node by a cluster-aware client; `MGET` across slots errors `CROSSSLOT`.
7. **Measure**: benchmark with `redis-benchmark -P <pipeline>`; watch `INFO commandstats`, `SLOWLOG`, and `--latency`.
8. **Connection reuse**: use a connection pool; opening a connection per batch destroys the gains.

Mark DESTRUCTIVE: unbounded pipelines / mega-batches (memory blowup, latency spikes for all clients), `KEYS *` inside a batch, `FLUSHALL`, `MONITOR`/`DEBUG` on prod, and giant `MSET` that stalls the event loop.

---

Workload: [DESCRIBE]
Client/volume: [DESCRIBE]
Latency/throughput now: [DESCRIBE]

Why this prompt works

Most “Redis is slow” complaints are actually network round-trip latency, not Redis. Pipelining collapses N round trips into roughly one, and multi-key commands do even better — but an unbounded pipeline just moves the problem to memory and tail latency. This prompt sizes batches sensibly, distinguishes pipelining from transactions, and grounds the tuning in redis-benchmark and SLOWLOG measurements.

How to use it

1. Describe the bulk pattern — thousands of small GET/SETs benefit most.
2. Report current RTT and throughput so the pipeline win is quantifiable.
3. Name the client library — pooling and pipeline APIs differ.
4. Say if you run Cluster — batches must respect slots.

Useful commands

# Benchmark with different pipeline depths
redis-benchmark -t set,get -n 100000 -P 1     # no pipelining
redis-benchmark -t set,get -n 100000 -P 16    # pipeline 16
redis-benchmark -t set,get -n 100000 -P 100   # pipeline 100

# Multi-key commands beat N single-key round trips
redis-cli MSET u:1 a u:2 b u:3 c
redis-cli MGET u:1 u:2 u:3

# CLI-side pipelining from a file of commands
cat commands.txt | redis-cli --pipe

# Where time goes
redis-cli INFO commandstats
redis-cli SLOWLOG GET 10
redis-cli --latency
redis-cli --intrinsic-latency 5

Example config

# redis.conf — surface slow ops and cap client buffers
slowlog-log-slower-than 10000      # microseconds (10ms)
slowlog-max-len 256
# Guard against a runaway client buffering huge pipeline replies
client-output-buffer-limit normal 0 0 0
maxmemory-clients 5%
tcp-nodelay yes

Common findings this catches

• One command per RTT → pipeline or use multi-key commands.
• Mega-batch → memory spike and tail-latency for all clients; chunk it.
• Pipelining assumed atomic → needs MULTI/EXEC.
• Connection per batch → no pooling; RTT savings lost.
• CROSSSLOT in Cluster → batch not split per node.
• Slow entries in SLOWLOG → oversized ops or KEYS in hot path.

When to escalate

• Throughput ceiling despite pipelining — evaluate sharding/Cluster.
• Tail latency from batch interference — coordinate client batch sizes.
• Network RTT dominated by topology — co-locate client and Redis.