Choosing application server for API backend

Question

With so many choices for the application server (Passenger, Thin, Unicorn, Mongrel, Puma and Rainbows!), I'm wondering what would be appropriate for the following scenario:

Rails is used purely for API backend (all assets are served with Nginx). Some of the API calls rely on other API services, so sometimes they take a while to finish.

The responsive app is used with mobile, tablet and desktop clients, so there's no guarantees about the client's connection.

What application server do you think is appropriate in this case? What things should be considered when choosing?

Haricot

Will this be on a Saas or a standalone server? – Apologetic

@TheIrishGuy: Standalone. – Haricot

Answer 1

If your application makes API calls to other services then Unicorn is a bad choice. Unicorn is a single-threaded multi-process application server, explicitly designed for fast, short-running CPU-bound workloads. Making HTTP API calls counts as long-running blocking I/O requests. This is not a limitation, but an explicit design choice of Unicorn. This is confirmed by the Unicorn website, section "Just Worse in Some Cases".

In theory Thin can handle such high-concurrency workloads because it uses evented I/O. However this requires explicit framework and application support in the form of evented code. Few frameworks and applications do this. Rails and Sinatra do not.

So this leaves only multithreading-capable application servers. The three contenders are Puma, Rainbows and Phusion Passenger 4 Enterprise.

• Puma is relatively new. Rainbows is slightly older but the author gives no guarantees about whether it works well. Phusion Passenger is mature, has existed for years, and is currently being used by over 150000 websites including large ones such as Pixar, New York Times, AirBnB, etc.
• Puma's and Rainbows's usage models are similar to Unicorn and Thin in that you start a bunch of processes and hook them into Nginx through a reverse proxy configuration. Phusion Passenger on the other hand is designed to integrate into Nginx directly, so it requires a lot less configuration, process management and other administration overhead.
• Phusion Passenger 4 Enterprise is not a strictly multithreaded server, but a hybrid multi-process/multithreaded one. This means it can run multiple processes (for increased stability and the ability to use multiple CPU cores), each one with multiple threads (for high I/O concurrency).
• Phusion Passenger 4 Enterprise bring many advantages over has more features than Puma and Rainbows: for example it has out of band garbage collection, can dynamically adjust the number of processes based on traffic, completely automates rolling restarts so you don't need scripting, etc.

You may also be interested in this writeup for more information.

Inion

Answer 2

The One True Way to know is to test and measure performances in real conditions. Anything else will be assumptions and guesses.

In the meantime, you should start with one you know to be good enough (unicorn seems to be a fairly popular and decent choice), and deal with server performance once it becomes a bottleneck.

Pentangular

+1 unicorn. Unicorn over Passenger. Additional questions would be if he'd be using workers. I'd go with thin to start off with if using Heroku. Puma or Unicorn behind nginx reverse proxy. – Apologetic

Answer 3

Based on your standalone req, I'd recommend a Puma or Unicorn server behind a nginx reverse proxy. Use sidekiq for worker queues. This is assuming a Rails app, if using Sinatra, thin might be good enough for ya. Like the other person said, write for stability first than test performance.

Apologetic