A Raspberry Pi study shows where Valkey spends its cores
A November Valkey study compares clock speed, I/O threading and multiple instances on constrained hardware. Its useful result is the relationship between workload, scheduling and memory access.
Adding I/O threads reduced throughput in one stage of David Tippett's November 21 Raspberry Pi study. The server had four cores, and the experiment selected five configured threads. Reducing the setting to two improved the reported results. That reversal is the useful story inside a post whose later tests exceed a million operations per second.
The experiment uses two Compute Module 4 machines, one serving Valkey and another generating requests. Its workload uses pipelining and very small values. These conditions belong to the result as much as the server configuration does. The published figures are measurements of that particular arrangement, not estimates for an arbitrary application using the same database.
The shown server command also disables snapshot saving. Its measured command path therefore does not include a representative schedule of background snapshots. That configuration is another reason to attach the reported throughput to the published experiment rather than to a general promise about a durable deployment.
I favour Valkey for the Redis model, which I have used since Redis's release. The study interests me because constrained hardware makes resource competition visible. More threads can move work off the main thread while still increasing the number of runnable tasks competing for the same physical cores.
Thread count includes the main thread
The earlier engineering explanation of Valkey 8's performance work, published in September, clarifies that io-threads includes the main thread. A setting of nine means eight I/O workers plus the main thread in its example. The configuration count should therefore not be interpreted as that many workers in addition to command execution.
On the Pi experiment's four-core host, a configured count of five exceeds the physical core count. The main thread and workers need scheduling opportunities, and the operating system still performs other work. Increasing the number of software threads does not create additional execution capacity. It changes how the existing work shares that capacity.
The configuration source linked by the study recommends leaving a spare core. It also describes threaded reads and writes as a way to move socket work away from the largely single-threaded server. That scope explains why the relationship between threads and throughput depends on the command workload.
The study reports different outcomes for SET and GET. Keeping those measurements separate is more useful than treating their arithmetic average as a universal request rate. They are distinct command paths, and the author explicitly leaves the reason for their difference unresolved. The experiment does not establish that every application should expect the same ratio.
A busy core can still wait for memory
The September engineering post supplies another mechanism relevant to the later Pi tests. After moving network work to I/O threads, its authors found substantial time in dictionary lookup. Dependent pointer accesses limited the processor's ability to overlap memory requests. A core could appear fully busy while much of its elapsed work involved waiting for data.
The optimization batches upcoming key lookups and interleaves the required accesses. Explicit prefetching brings dictionary entries toward the processor before command execution needs them. This is different from making several threads modify the dataset concurrently. The execution path can improve because it has earlier knowledge of future accesses.
The linked configuration documents a prefetch batch-size setting and says zero disables the mechanism. Its default batch size is sixteen. That gives the implementation another adjustable quantity besides the number of I/O threads. The amount of useful future work available in a batch depends on how commands arrive and which keys they access.
This explains why full CPU utilization alone cannot identify the remaining bottleneck. Scheduling competition and dependent memory access can both affect the same visible utilization figure. The useful evidence comes from connecting the measurement to the work the processor performs, rather than assuming a busy core has no further efficiency available.
Multiple instances change the execution arrangement
The Pi study's final stage runs several clustered instances on the server host. That is a different arrangement from adding more I/O workers to one instance. Separate instances have separate command-execution threads and divide responsibility for keys. The resulting throughput therefore reflects another way of using the machine's cores.
It also changes the client-side workload path. The benchmark becomes cluster aware so it can reach the appropriate instance for its keys. A result from that stage includes the cluster arrangement and key distribution, which cannot be inferred from a single-instance thread-count setting.
My preference is to read the experiment as a set of explanations for changing resource use. One stage adds too many runnable threads for the host, another reduces memory-access delays, and the final arrangement distributes command execution across instances. The million-operation result belongs to the last arrangement, while the thread-count reversal remains evidence about the earlier single-instance setup.