Redis Pipeline Calculator

Give the command count and the network round-trip time. The result shows the sequential and pipelined timings and where the difference comes from.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Calculate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A hundred thousand commands

Over a typical network round trip, where pipelining is transformative

commands: 100000
rtt-ms: 0.5
pipeline-depth: 200

Too large a batch

A batch big enough to risk the client output buffer limit

commands: 1000000
rtt-ms: 0.5
pipeline-depth: 50000

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Treating a pipeline as a transaction

    Commands from other clients interleave freely between pipelined commands. Only MULTI/EXEC or a script is atomic.

    Instead:Use MULTI or Lua where atomicity is required.

  2. Batching without bound

    The client holds every reply and the server buffers the output. A very large batch can trip client-output-buffer-limit and have the connection closed.

    Instead:A few hundred to a few thousand captures almost all the benefit.

  3. Pipelining over a unix socket and expecting a large gain

    The saving is round trips, and a local socket round trip is already tiny.

    Instead:Measure first. The benefit scales with network latency.