Geek Answers Handbook

Choosing an Application Server for the API

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

Rails is used exclusively for the API backend (all assets are served using Nginx). Some API calls rely on other API services, so sometimes they take time to complete.

A responsive application is used with mobile, tablet and desktop clients, so there are no guarantees regarding the connection to the client.

Which application server do you think is appropriate in this case? What to consider when choosing?

+6
source share
3 answers

If your application calls API calls to other services, then Unicorn is a bad choice. Unicorn is a single-threaded multiprocessor application server, clearly designed for fast and short work with CPU load. HTTP API calls count as long blocking I / O requests. This is not a limitation, but an explicit choice of Unicorn design. This is confirmed by the Unicorn website , “Worse, in some cases” section.

In theory, Thin can handle such high concurrency workloads because it uses I / O events. However, this requires explicit support for frameworks and applications in the form of an event code. It makes several wireframes and applications. Rails and Sinatra do not.

Thus, this leaves only multithreading application servers. Three applicants: Puma, Rainbows, and Phusion Passenger 4 Enterprise .

  • Puma is relatively new. Rainbows are a bit older, but the author makes no guarantees as to whether he works well. Phusion Passenger is mature, has existed for many years and is currently used by more than 150,000 websites, including large ones like Pixar, New York Times, AirBnB, etc.
  • The usage models of Puma and Rainbows are similar to Unicorn and Thin, since you start a bunch of processes and connect them to Nginx through the reverse proxy configuration. Phusion Passenger, on the other hand, is designed to integrate directly with Nginx, so it requires much less configuration, process management, and other administrative overhead.
  • Phusion Passenger 4 Enterprise is not a strictly multi-threaded server, but a hybrid multi-processor / multi-threaded server. This means that it can run several processes (to increase stability and the ability to use multiple processor cores), each of which has several threads (for high I / O concurrency).
  • Phusion Passenger 4 Enterprise brings many advantages , has more features than Puma and Rainbows: for example, it has out-of-band garbage collection, can dynamically configure the number of processes based on traffic, fully automate restart restart, so you do not need scripts, etc.

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

+13
source

The only true way to know is to check and measure performance in real conditions. Everything else will be assumptions and assumptions.

At the same time, you should start with someone you know to be good enough (a unicorn seems to be a pretty popular and decent choice), and deal with server performance as soon as it becomes a bottleneck.

+3
source

Based on your standalone req, I would recommend a Puma or Unicorn server for a nginx reverse proxy. Use sidekiq for work queues. This assumes a Rails application, if you use Sinatra, thin can be good enough for ya. As another person said, write about stability in the first place than the performance of the test.

+2
source

More articles:


All Articles