,
7 tweets,
2 min read
Read on Twitter
Redis threaded I/O small (sic) thread. So results confirmed, works great in the write side, I'll have to implement it in the read side as well. Using 4 threads it is simple to get 2x the performances of single-threaded Redis (even if yet the reading part is not threaded).
So, what's the idea here? Some people say that Redis should be threaded, a few created forks that are quite more complex. But the reality is that Redis uses a lot of time just in the reading/writing part (to the socket and in the client structure).
So... 1.5 years ago I started this project (first commit 2d546a79 is Oct 24 2017!) with this idea: Instead of making Redis threaded I just "fan out" to N threads once I need to write to (or read from) N clients.
No complexity, but most of the advantages, because the *majority* of time Redis spends is there. However the tricky part is: don't lose the advantage in threads synchronization. But with _Atomic it is possible to do many magics.
However initially (1.5 years ago) I used trivial synchronization primitives and gave up for lack of time. I tried again this time more motivated and now it works great. Next step? Threading the read part.
I'll explain it all at Redis Conf in San Francisco, 2nd of April in my keynote, together with the other news about Redis 6 (ACLs and so forth). The code is in the threaded-io branch, and will be maintained there. Have fun improving / testing it :-D
One thing to note: to see the benefits make sure to A) make distclean; make; ./redis-server --io-threads <count>. B) also use the new threaded redis-benchmark. ./redis-benchmark --threads 8 -t get -n 10000000 or alike.
