Implicit pipelining is slightly slower than not pipelining

[kimtree]

Hi guys, I still keep on my eyes on Radix project!

This issue came from the first time that I applied Radix in our production product. We noticed that our latency was slightly slower by 1~2 ms and we've got the hint from the pprof. We saw some of pipelining relative codes are showed up in profiling image.

I've tried a simple test with the latest commit and this is the result.

• Common Option
  • Benchmark Machine CPU: 20 CPU
  • Redis version: 4.0.10 (3 shards * 2 nodes)
  • Pool Size: 20

Option 1) With implicit pipelining (no other options)

Benchmark/hkeys-40                 5000000             10041 ns/op             282 B/op          7 allocs/op

Option 2) Without implicit pipelining and add options

• radix.PoolPipelineWindow(0, 0)
• radix.PoolOnEmptyCreateAfter(0)

Benchmark/hkeys-40                 5000000              9079 ns/op             307 B/op          7 allocs/op

We're handling 25,000+ req/s in our production service, and I think 1000 ns difference can be affected our latency. Any ideas on this?

[kimtree]

Oh, It seems to run the benchmark for each person's environment. I'll close this issue and let people can refer to this benchmark result :)

• Just set radix.PoolPipelineWindow(100 * time.Microsecond, 0)

BenchmarkTestQPS/simple-hkeys-40                 5000000              8942 ns/op             284 B/op          7 allocs/op

• radix.PoolPipelineWindow(75 * time.Microsecond, 0) ! Seems best for me

BenchmarkTestQPS/simple-hkeys-40                 5000000              8634 ns/op             286 B/op          7 allocs/op

• radix.PoolPipelineWindow(50 * time.Microsecond, 0)

BenchmarkTestQPS/simple-hkeys-40                 5000000              9868 ns/op             289 B/op          7 allocs/op

[nussjustin]

The default of 150us was chosen as it's the recommended value for production in https://github.com/joomcode/redispipe (where we got the inspiration for the implicit pipelining from). There is no other hard reasoning behind it and we could even change it in the future if it turns out too be too much for the common case, but the "correct" value will always depend on the workload and requirements.

[kimtree]

@nussjustin Thanks for the information!