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
