Speech of Dmytro Herasymuk, WEB developer at Softermii, at Ruby Meditation #25 Kyiv 08.12.2018 Next conference - http://www.rubymeditation.com/ The modern world demands to be faster and faster. Engineers create more powerful CPUs every day, but our app depends on third party apps too often in the WEB world. So, even the fastest CPU can't cope with I/O delays. On the one hand multithreading could help in such cases, but on the other hand, it seems to be a hard decision of using concurrency in production. Dmytro would like to share his experience in this field Announcements and conference materials https://www.fb.me/RubyMeditation News https://twitter.com/RubyMeditation Photos https://www.instagram.com/RubyMeditation The stream of Ruby conferences (not just ours) https://t.me/RubyMeditation

1. Concurrency in production
Real-life example

2. Why do we need concurrency?

3. Program execution ways

4. Why don’t we use it so often?
Multithreaded programming

5. The Global Interpreter Lock
MRI has a Global Interpreter Lock, often called the GIL, and having a high level
understanding of it is important to understanding how we write multi-threaded code
in Ruby. Basically the GIL prevents multiple Ruby threads from executing at the same
time. This means that no matter how many threads you spawn, and how many cores
you have at your disposal, MRI will literally never be executing Ruby code in multiple
threads concurrently. Note that this is not the case for JRuby or Rubinius which do not
have a GIL and offer true multi-threading.
The existance of the GIL provides some guarantees and removes certain issues around
concurrency within MRI. It’s important to note however that even with the GIL it’s
very possible to write code which isn’t threadsafe in MRI.

6. So when does using threads make sense?
To ensure all citizens are treated fairly the underlying operating system handles
context switching between threads, i.e. when to pause execution of one thread and
start or resume execution of another thread. We said above that the GIL prevents
multiple Ruby threads within a process from executing concurrently, but a typical
Ruby program will spend a significant amount of time not executing Ruby code,
specifically waiting on blocking I/O. This could be waiting for HTTP requests, database
queries or file system operations to complete. While waiting for these operations to
complete, the GIL will allow another thread to execute. We can take advantage of this
and perform other work, which doesn’t depend on the result, while we wait for the I/O
to finish.

7. What does it mean in practice?

8. Issue

9. The first idea
Let’s do it on client side...

10. Performing HTTP requests concurrently
At a high level this should
get our timeline waiting for
GET requests from this:
to this:

13. Thanks for your
attention!
Hope you don’t have
questions ;)