Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead.
Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a great tradeoff when you don't really need sub-millisecond performance but want the same API across a larger dataset limited by disk instead of RAM space.
>> What are the advantages of "multi-threading" other than for performance?
> Taking advantage of all your cores.
Uh, is there any reason you'd want to "take advantage of all your cores" other than performance?
The question/proposal/dialog we started from, don't forget, was:
1. Redis is already as performant as I want, it's not even close to being a bottleneck, so I have no need for multi-threading, and this is a _very very common_ case, as redis is performant enough for a lot.
2. There are other advantages of multi-threading than performance. (Ie, other reasons you'd want it despite 1).
You seem to just be going around in circles. If 1, why would you care about "taking advantage of all your cores"?
Sure, I concede multithreading is for performance. Still, the second point of having Redis structures available over a dataset that isn't limited by RAM is a big advantage.
Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a great tradeoff when you don't really need sub-millisecond performance but want the same API across a larger dataset limited by disk instead of RAM space.