Question

I’m contemplating writing a web application with Rails. Each request made by the user will depend on an external API being called. This external API can randomly be very slow (2-3 seconds), and so obviously this would impact an individual request.

During this time when the code is waiting for the external API to return, will further user requests be blocked?

Just for further clarification as there seems to be some confusion, this is the model I’m anticipating:

1. Alice makes request to my web app. To fulfill this, a call to API server A is made. API server A is slow and takes 3 seconds to complete.
2. During this wait time when the Rails app is calling API server A, Bob makes a request which has to make a request to API server B.

Is the Ruby (1.9.3) interpreter (or something in the Rails 3.x framework) going to block Bob’s request, requiring him to wait until Alice’s request is done?

Answer 1

If you only use one single-threaded, non-evented server (or don’t use evented I/O with an evented server), yes. Among other solutions using Thin and EM-Synchrony will avoid this.

Elaborating, based on your update:

No, neither Ruby nor Rails is going to cause your app to block. You left out the part that will, though: the web server. You either need multiple processes, multiple threads, or an evented server coupled with doing your web service requests with an evented I/O library.

@alexd described using multiple processes. I, personally, favor an evented server because I don’t need to know/guess ahead of time how many concurrent requests I might have (or use something that spins up processes based on load.) A single nginx process fronting a single thin process can server tons of parallel requests.