Redis and threading (or lack thereof)



Redis is fast — wicked fast. Blazing fast even.
Most of this is because, for the longest time, its core event-loop was just a (very!) lightweight wrapper around epoll/kqueue/whatever, with almost all the focus placed on nom-blocking behavior.
Herewith a nifty walkthrough of the internals — https://goo.gl/gUzCN — in the context of building concurrent systems focused on sheer performance. (°)
BTW, there is actually some threading in there now. Freeing memory and fsync/persistence are now handled by a — strictly controlled! — set of redis specific background threads.
There are also “long running user ops” (warning — here be Dragons!) that spin up their own threads. #TIL
(°) This nugget — createClient’s… sets the socket to non-blocking mode (a key ingredient in an asynchronous event loop) — brought back a lot of unpleasant memories. It may have been the single most common issue I’ve seen in networking code. Or made, for that matter

Comments

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

Spot The Difference — Deep Learning Edition