why so slow compared with redis? about mini-redis

[Darksonn]

Probably because the hash map is protected by a single mutex instead of doing something more clever.

[hiqsociety]

that's all? it's really very very slow.

[Darksonn]

Another difference is that mini-redis does not support pipelining.

[carllerche]

It is doubtfully the mutex and probably pipelining. When running benchmarks, be sure to not pipeline.

[MeirShpilraien]

What is the reason pipeline is so slow? I see that when I use pipeline on redis-benchamrk the CPU drop to almost zero usage.

[carllerche]

Because pipelining in mini-redis is not implemented.

[MeirShpilraien]

Thanks @carllerche but what is require to implement it? Why the fact that the client sends another command before getting the pre command reply causes such a CPU drop (and with it a performance drop)?

[Darksonn]

Pipelining requires that you can start processing the next message before responding to the first. Mini-redis will not implement it.

[MeirShpilraien]

I agree it will be far from Redis performance but I do not understand why it is so bad. With pipeline of 2 I got like 40 ops/sec and CPU usage drop to around 1%. Why the processes stays idle for so long?

[MeirShpilraien]

OK, I think I found the answer, if I set TCP_NODELAY flag the performance are not dropped so drastically and we can even gain better performance from pipeline.

Without TCP_NODELAY:

> redis-benchmark -c 1 -n 1000000 -P 2 get x
WARNING: Could not fetch server CONFIG
get x: rps=47.8 (overall: 45.8) avg_msec=0.449 (overall: 0.430)

With TCP_NODELAY:

> redis-benchmark -c 1 -n 1000000 -P 2 get x
WARNING: Could not fetch server CONFIG
get x: rps=60672.0 (overall: 59762.0) avg_msec=0.020 (overall: 0.021)