Posted about 1 month ago. Visible to the public.

Rails: Concurrent requests in development and tests

With puma you can have concurrent requests. There are two concepts on how Puma can handle two incoming requests: Workers and Threads.

Workers

Puma can have multiple workers. Each worker is a process fork from puma and therefore a very heavy instance and can have multiple threads, that handle the incoming requests.

Example: A Puma server with 2 workers and 1 thread each can handle 2 request in parallel. A third request has to wait until the thread of one of the workers is free.

Threads

Rails is thread-safe since version 4 (note that not all gems are thread-safe). This makes it possible to use threads in Puma to process multiple requests in a single worker. These requests are not processed in parallel, but once one thread is blocked, another can continue.

Example: A Puma server with 1 worker and 2 threads can handle 2 requests. A third request has to wait until one of the two requests is finished.

Concurrent requests in development and tests

Normally having multiple threads for development is fine. Puma can handle blocking threads e.g. when you place a debugger only the current request is blocked and you can still visit other sites.

In case you want to request your own application in a request itself, Puma will not allow other threads to be processed. In this case you have a deadlock until you get a request Net::Timeout from the inner request. You can fix it by setting the number of workers >= 2.

Example for the related config/puma.rb:

Copy
workers Integer(ENV['WEB_CONCURRENCY'] || 2) threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 5)

Note: Having multiple workers in development and tests might cause unexpected issues (database transactions and other shared states), you should not enable it just for fun. Use bundle exec puma -t 0:1 -w 1 -p 3000 to debug concurrency issues.

Legacy

Settings like config.allow_concurrency = false, config.threadsafe! and config.middleware.delete Rack::Lock seems not to be relevant for Rails >= 4 anymore.

By refactoring problematic code and creating automated tests, makandra can vastly improve the maintainability of your Rails application.

Owner of this card:

Avatar
Emanuel De
Last edit:
about 1 month ago
by Emanuel De
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Emanuel De to makandra dev
This website uses cookies to improve usability and analyze traffic.
Accept or learn more