Member-only story
Scalable Ruby — Concurrency and Parallelism Explained
And why the differences matter
Years ago, Ruby ruled the web. It was very easy to build new apps, there were many gems that solved common problems, and, therefore, it was easy to build new features.
But then things changed. Twitter struggled to make Ruby scale and switched to different platforms to satisfy the performance requirements they had. More and more voices pointed out that Ruby was too slow and unable to handle the demands of the web.
This gave rise to new technologies that scaled easier, that scaled better. Node especially satisfied this demand and created a new hype around it. Other technologies that popped up as well were Golang, Elixir, and Scala/Akka, to name a few.
Note: When I am talking about concurrency in Ruby, I will not talk about multi-process architecture or how to use load balancers. The goal of this piece is to show how to make use of concurrency in Ruby within one process, and to show the difference between parallelism and concurrency.
How did Node achieve this scalability? Node runs on the V8 JavaScript engine and employs a very sophisticated and fast event loop. With the help of this and non-blocking IO operations, Node can handle a massive amount of parallel incoming requests.
Does this mean that Node runs all this requests in parallel too? Actually, no. The event loop and non-blocking IO operations make it possible for the V8 to run the requests concurrently, but not in parallel.
“Wait, what?” I hear you say. “What is the difference and why should I care?”
What Is Concurrency and Parallelism?
Concurrency
A very accurate definition of concurrency I found is this:
“The coordination and management of independent lines of execution. These executions can be truly parallel or simply be managed by interleaving. They can communicate via shared memory or message passing.”
When talking about concurrency I will talk only about the managed by interleaving type of concurrency.
Let’s explain concurrency with the example of Node, since many know Node and (nearly)…
