Across five one-hour Valkey 9.0 runs on Amazon ElastiCache cache.t4g.micro, tripling the load-generator workers from three to nine increased mean throughput by 55.8%, nearly doubled client latency, and raised the mean eviction count to 2.47 times the three-worker level.

All five memtier_benchmark runs used the same Valkey 9.0, single-node Amazon ElastiCache cache.t4g.micro target. Two runs used three workers, three used nine. The comparison shows what additional client concurrency does to a small cache approaching its memory boundary: throughput rises, but far less than the worker count.

Five runs, one cache configuration

Configuration means

Three times the workers, 1.56 times the throughput

The three-worker runs delivered between 5,512 and 5,966 ops/s, with a mean of 5,739 ops/s. The nine-worker runs delivered between 8,726 and 9,252 ops/s, averaging 8,942 ops/s.

That is a useful throughput gain, but not a scaling curve. Worker count increased by 200%, while mean throughput increased by 55.8%. The result is consistent with the unchanged cache node becoming the limiting resource as offered concurrency rises within the same CPU and memory envelope.

Operationally, the additional workers increase offered load. Cache capacity remains unchanged.

The throughput gain came with almost twice the latency

Average client latency was tightly grouped between 1.00 and 1.09 ms with three workers. With nine workers, every run landed between 1.94 and 2.06 ms. The configuration mean rose from 1.045 to 2.010 ms-an increase of 92.3%.

This pattern is consistent with additional queueing or contention under the heavier offered load. The node completed more operations per second, while individual operations took longer. For a latency-sensitive workload, the additional 3,203 mean ops/s should therefore be evaluated together with the higher response time.

More workers reached the memory boundary earlier

All five runs eventually reached 100% reported memory, so neither configuration represents a clean headroom test. The difference is how quickly and how aggressively each group entered the eviction regime.

With three workers, the first eviction appeared after an average of 33 minutes 09 seconds. With nine workers, it appeared after 21 minutes 27 seconds-about 11 minutes 42 seconds earlier. Mean eviction count rose from 95,073 to 234,864, which is approximately 2.47 times the three-worker mean.

Average memory use also moved from 80.75% with three workers to 88.29% with nine. The higher-concurrency runs crossed the usable memory window sooner and sustained substantially more key churn after saturation.

The higher-load runs were less predictable

The two three-worker runs were relatively close, with throughput coefficients of variation of 25.0% and 27.9%. The nine-worker results ranged more widely, from 28.4% to 52.0%, with a mean of 41.6%.

Peak throughput makes that variability especially visible: the nine-worker runs peaked between 27,080 and 42,446 ops/s, far above their 8,726-9,252 ops/s averages. Those peaks describe short-lived bursts rather than sustained cache capacity. For planning, the repeat-run averages, latency, and eviction behavior are the safer signals.

Hit rate improved while eviction pressure increased

Mean cache hit rate increased from 61.25% with three workers to 66.1% with nine. Viewed alone, that might suggest better efficiency. The wider metric set tells a different story: the nine-worker configuration recorded 2.47 times the mean eviction count and entered eviction pressure earlier.

Hit rate describes the share of lookups served from the cache. It does not capture the key churn required to maintain that share, the time each request spent waiting, or the remaining memory headroom. The result is only meaningful when those signals are read together.

Practical read

• Three workers provide the calmer baseline: approximately 1 ms average client latency and a later transition into eviction pressure.
• Nine workers provide the heavier-load case: higher served throughput and a longer period under sustained memory pressure.
• The nine-worker configuration is not a capacity upgrade: the unchanged node trades higher throughput for more latency, earlier eviction, greater key churn, and a less consistent run shape.
• Node scaling is the relevant step when the requirement is headroom: additional load generators reveal the existing boundary but do not move it.

For the broader node-size and processor-architecture context, see the Valkey 9.0 T3 versus T4g comparison across micro, small, and medium nodes.

Where this comparison stops

This comparison covers five completed one-hour runs: two at three workers and three at nine. The repeat counts are unequal, and both configurations eventually reached maxmemory. The figures describe two levels of offered load under eventual memory pressure, not a universal worker-scaling law.

A full scaling curve would require additional worker counts, equal repeat counts, and a cache configuration with enough memory headroom to separate client-concurrency effects from eviction behavior. Within this result set, the direction remains consistent: tripling workers produces materially more load but only 55.8% more sustained throughput, accompanied by almost double the latency and substantially heavier eviction pressure.