Here at Cloud 66 we do loads of work with external resources (ie. user’s servers; generic infrastructure components like Load Balancers, Hardware firewalls, Disks etc). And often times we need to operate on these components as part of a synchronous workflow.

Consider the following (extremely simplified) workflow:

Now, normally we would use sidekiq to perform our background processing, however, in workflow scenarios like the above where we want to synchronously wait on some operations to be performed in parallel then sidekiq doesn't quite fit the bill (we end up with a proliferation of jobs and batches that become very complex as the number of parallel operation in the same workflow increase). So, in this case, we'll roll our own.

What about the GIL

The one thing these operations all have in common is that they are all I/O bound processes (and NOT compute bound). I/O bound processes essentially means that our processes are not CPU calculation intensive but rather are spending time waiting on some other resource - in this case, network comms from our cloud provider. This is important thanks to our ever-present Global Interpreter Lock (GIL) (ps. check out this really good read on the GIL). By focusing on I/O bound processes we can benefit from concurrency performance gains in Ruby.


The basic implementation resolves around a few core concepts:
1. We use our own lambda context object to define our lambda methods and store our run results after operation
2. We use Ruby native Thread Local Storage (TLS) to store our operation states and run results during operation
3. We use a new ActiveRecord db connections for each thread operation. This ensures that we don't illegally re-use or close active db connections

Class: LambdaContext

First we need to define a class called LambdaContext which serves simply to store our lambda definition and run-results:

Now we can simply create a collection of these lambda_context objects to run in parallel later on. From our sample workflow (assuming of course that the method create_server with parameter server_index exists):

Note: we are passing in our svr_idx argument ourselves (instead of defining the lambda directly with the value of idx). In the above example it makes little difference, but in a case where the value of idx could change before the lamdba executed (reference value) we would want to be able use the reference value we originally wanted.

Class: ThreadRunner

We can now define a class to perform the operations in parallel using Rubies native Thread class implementation:

Example Usage

Now, using the classes above for our workflow as defined above we can simply do the following:


In this blog post, we looked at a relatively simple multithreading solution in Ruby to provide significant performance improvements in running I/O bound operations in parallel specifically when we need to join on their results and continue. Next time we’ll take a look at some improvements we can make to this class around limiting concurrency and using a thread pool.

Happy coding!

Originally published at on August 22, 2017.

DevOps-as-a-Service to help developers build, deploy and maintain apps on any Cloud. Sign-up for a free trial by visting: