What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Redis Cluster can have far more capacity than a benchmark client is able to use. In a 48-shard test reported by Sunny Sahijwani at Two Techies on 4 September 2026, a single cluster-mode memtier client delivered 4.6 million operations per second; dedicated clients feeding the shards separately delivered 39.8 million ops/s in the detailed run, with server CPU at 91%. The gap was attributed to client-side routing and load-generation limits, not a fixed limit of Redis Cluster. These are results from one benchmark setup, not general performance guarantees.
What the 4.6M-versus-40M comparison actually shows
The comparison is about how effectively a particular client workload used a particular 48-shard Redis Cluster. Sahijwani’s detailed result was 39.8M ops/s with per-shard clients; the article also uses 40.6M in its introduction and image caption. “About 40M” is the fairest shorthand, while 39.8M is the detailed figure. The benchmark author reported 4.6M ops/s for the normal cluster-mode client.
The same account describes an initial read-heavy test in which increasing the cluster from 24 to 48 shards barely changed measured throughput: 2.65M versus 2.66M ops/s with pipeline depth 16. The author reports server CPU around 16% while load-generator threads were near 100%. Adding client threads reportedly reduced observed throughput from 4.3M to 3.0M. The author interpreted these results as evidence of client-side saturation and lock contention.
Those numbers and the diagnosis are reported by the benchmark author, not independently reproduced here. The article says its harness and raw data are public. Its “normal client” result is specifically about memtier cluster mode under heavy pipelined load; a production application using a capable client library at a modest request rate may not encounter the same limit.
#1 Best Overall
How a client can hold back a Redis Cluster
Redis Cluster divides data among master nodes using 16,384 hash slots. A client uses key-to-slot information to route a command to the node that owns that slot; ordinary commands are not simply sent to one node that forwards them to the right shard. The client therefore has work to do before Redis can process each operation: determine the destination, organize requests, manage connections, send commands, and consume replies.
Adding shards increases the cluster’s potential parallelism, but it does not automatically make one client able to generate and route work fast enough to use all of them. If client CPU is saturated while shard CPU remains low, the client, its routing path, or its workload generator is a more plausible bottleneck to investigate than server capacity alone. This is a diagnostic clue, not proof: measure the actual application and benchmark conditions.
Rank #2
Why configured pipeline depth can mislead
Pipelining sends multiple commands before waiting for their replies. Batching can reduce repeated network round trips and socket I/O system calls, improving throughput. But a configured pipeline depth is not necessarily the effective batch size each shard receives.
In the reported example, a batch of 16 random-key commands could be split across several shard connections. If requests are distributed among destinations, each individual connection may receive only a few commands before the client waits for replies. The benchmark can say “pipeline depth 16” while the work reaching any one shard is much less deeply pipelined. Redis also queues replies, consuming memory, so arbitrarily large batches are not a safe universal fix; use bounded batches and observe memory and latency as well as throughput.
Rank #3
What changed in the higher-throughput run
The author changed the way work was delivered: hash-tagged benchmark keys were directed to shard slot ranges, and a dedicated client process drove each shard with deep pipelines. That arrangement reduced the per-client routing and batching burden and kept each shard supplied with work. Sahijwani reports 39.8M ops/s across 48 dedicated client processes at 91% server CPU.
For context, the same article reports 474,000 ops/s for one standalone shard pinned to one core at 100% CPU. That single-shard measurement is not a reliable formula for predicting total cluster throughput: the reported multi-shard run achieved a different result under its own setup and workload. The useful conclusion is that measured cluster throughput depends on how the client feeds the shards, not that a per-core extrapolation guarantees a particular cluster total.
Rank #4
How to diagnose a client-side throughput ceiling
- Measure both sides. Record client CPU and thread utilization alongside per-shard CPU, throughput, and latency. A saturated generator with mostly idle Redis shards points toward a client-side ceiling; it does not by itself identify which client operation is responsible.
- Check destination-level batching. Determine how many commands are actually grouped for each node, not just the pipeline depth configured at the application level. Random keys, many shard destinations, and small batches can leave each connection with little work.
- Inspect routing and concurrency. Check whether the client maintains and refreshes the slot map appropriately, how it groups pipeline commands by destination, and whether requests to different nodes run concurrently. More threads are not automatically better: the reported benchmark saw throughput fall after adding client threads.
- Use representative keys and operations. Benchmark the actual key distribution, command mix, payload sizes, and concurrency pattern. A test that concentrates keys on selected shards can show what the cluster can do under that pattern, but may not represent an application whose keys are spread differently.
- Track latency and resource costs. Compare throughput together with latency, queued reply memory, client CPU, and shard CPU. A higher ops/s result is not a useful improvement if it breaches latency targets or consumes unacceptable memory.
When hash tags help—and when they do not
Redis hash tags let keys containing the same tag map to the same hash slot. For example, keys such as account:{42}:profile and account:{42}:events share a slot because the text inside braces is used for slot calculation. This can enable multi-key operations that require participating keys to reside in the same slot, and it can make a benchmark direct work to chosen slots.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Co-location is a data-placement decision, not a free throughput optimization. Concentrating too many requests on a subset of slots can leave other shards underused and create hot shards. Use tags only when the application’s access patterns and same-slot requirements justify them; do not reshape production keys solely to reproduce a benchmark result.
Best Value
What to look for in a Redis client
Client behavior varies, so compare implementations under the workload you actually run rather than declaring one universally fastest. Redis-py documents cluster pipelines that group commands by destination node and execute them in parallel. The ioredis documentation describes automatic per-node pipelining and reports a 35%–50% improvement in its own benchmarks; that is a project-reported, library-specific result, not a general expectation for applications.
- Does the client route using the cluster slot map and handle map updates?
- Does it batch commands separately for each destination node, and can you observe the resulting batch depth?
- Can work for multiple nodes proceed in parallel?
- How do client CPU, thread contention, and connection counts change as concurrency rises?
- Does its behavior remain effective with your key distribution and command mix?
Throughput tuning does not change Redis Cluster consistency
Faster routing, more effective pipelines, or additional clients do not strengthen Redis Cluster’s write-consistency guarantees. Redis documents replication as asynchronous by default; acknowledged writes can be lost in specified failover or partition situations. The WAIT command can reduce the likelihood of write loss, but it does not provide strong consistency. Choose and validate durability behavior separately from throughput tuning.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors
