A potential performance regression due to #2652
Noticed that this commit 48e0cbb is effecting the performance of GET commands from 2.7M to 2.0M rps for 96 bytes data size, 9 IO-Threads and 10 Pipelining.
This is about 25% drop
You can see more here
Methodology
These benchmarks are generated using the valkey-perf-benchmark framework which used valkey-benchmark on a c8g.metal.2xl instance, running a matrix of configurations that vary pipelining (1, 10), I/O threading (1, 9), and data sizes (16,96,2048). To further stabilize results, we apply IRQ tuning by pinning network interrupts away from CPUs dedicated to the server process, and we isolate the server and benchmark client on separate NUMA nodes to remove L3 cache contention. This controlled methodology ensures consistent, repeatable comparisons across versions and makes performance gains or regressions easier to attribute to real code changes rather than environmental variability.
FYI @enjoy-binbin
A potential performance regression due to #2652
Noticed that this commit 48e0cbb is effecting the performance of GET commands from 2.7M to 2.0M rps for 96 bytes data size, 9 IO-Threads and 10 Pipelining.
This is about 25% drop
You can see more here
Methodology
These benchmarks are generated using the valkey-perf-benchmark framework which used valkey-benchmark on a
c8g.metal.2xlinstance, running a matrix of configurations that vary pipelining (1, 10), I/O threading (1, 9), and data sizes (16,96,2048). To further stabilize results, we apply IRQ tuning by pinning network interrupts away from CPUs dedicated to the server process, and we isolate the server and benchmark client on separate NUMA nodes to remove L3 cache contention. This controlled methodology ensures consistent, repeatable comparisons across versions and makes performance gains or regressions easier to attribute to real code changes rather than environmental variability.FYI @enjoy-binbin