A hundred thousand commands
Over a typical network round trip, where pipelining is transformative
commands: 100000 rtt-ms: 0.5 pipeline-depth: 200
Give the command count and the network round-trip time. The result shows the sequential and pipelined timings and where the difference comes from.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
Over a typical network round trip, where pipelining is transformative
commands: 100000 rtt-ms: 0.5 pipeline-depth: 200
A batch big enough to risk the client output buffer limit
commands: 1000000 rtt-ms: 0.5 pipeline-depth: 50000
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
The saving is round trips, and a local socket round trip is already tiny.
Instead:Measure first. The benefit scales with network latency.