|Home » Categories » Multiple Categories|
A Comparison of (Rack) Web Servers for Ruby Web Applications
Article Number: 232 | Rating: Unrated | Last Updated: Mon, Dec 30, 2013 at 2:21 AM
Meet Ruby's RackNowadays, giving the opportunity to mix-and-match web servers with web applications and other technologies [to developers] is a very powerful, necessary and indeed in-demand aspect of any programming language and framework. A very basic example for this is the need of different environments for development, testing and/or production.
With the goal of making this happen, in 2007 Christian Neukirchen released Rack, what he then referred to as "a modular Ruby webserver interface". Today it is adapted by numerous web servers and web application development frameworks such as Espresso, Mack, Ruby on Rails, Sinatra etc.
Despite the naming conventions and assorted explanations across [programming] languages and domains, specifications for interfacing [applications] are very similar, if not homologous (although unlike Python's WSGI -- an inspiration to Rack and others, Rack here is not only a specification but -- perhaps a little confusingly -- a middleware application as well).
Rack middleware (gem), implementing the Rack specification, works by dividing incoming HTTP requests into different pipelined stages and handles them in pieces until it sends back a response coming from your web application (controller). It has two distinct components: a Handler and an Adapter, used for communicating with web servers and applications (frameworks) respectively.
About The ComparisonIn this comparison, we will talk about some of the popular and available web application server choices today. We will go through what makes one stand out against the other and how they differ in certain aspects from the rest. The aim here is to enable you to have a better overall understanding in order to be able to match servers with your application's needs to craft the solution you require.
Web Servers (in Alphabetical Order)Phusion Passenger: Fast web server & app server
Passenger today has become the recommended server for Ruby on Rails applications. It is a mature, feature rich product which aims to cover necessary needs and areas of application deployment whilst greatly simplifying the set-up and getting-started procedures. It eliminates the traditional middleman server set up architecture by direct integration within Apache and NGINX (front-facing) web servers. It is also referred to as mod_rails / mod_rack for this very reason amongst the Ruby (Rails) community.
NotesPassenger provides the ability to work with multiple applications hosted on the same server.
It is capable of handling slow clients. Requests and responses with Passenger are fully buffered, rendering itself immune to such attacks targeting to clog systems' resources.
Passenger is highly popular and used widely in many [production] scenarios. It is therefore possible to reach out and find experts and also have your issues addressed in online communities. It also has a dedicated company developing the product, which offers efficient commercial support for those interested.
Its open-source version has a multi-process single-threaded operation mode, whilst the Enterprise version can be configured to work either single-threaded or multi-threaded.
For enterprise users, Passenger provides some further "advanced" features such as: concurrency and multithreading, deployment en masse, resource control and limiting, et al.
Puma: A Modern, Concurrent Web Server for RubyPuma is a Rack exclusive Ruby web application server. Its creation and birth is heavily inspired by the legacy Mongrel web server, which had revolutionized a lot during the time it was released and affected how Ruby applications were served for many generations (of servers) to come. Puma's developer, Evan Phoenix, deciding to move things forward, transformed Mongrel's operational structure to solely operate on Rack (and thus eliminating complexities causing performance decay) and designed the application to support true parallelism, which allows concurrency (explained further below).
NotesThe application has quite a small foot print, both in size and execution resources consumption.
Puma has several working modes: it allows you to set the amount of minimum and maximum threads it can use to do its job and also works in a clustered mode whereby you can use forked processes to handle requests concurrently.
It is based on Mongrel's parser -- and a lot of rewrites of its codebase.
Despite being designed as "the go-to server" for Rubinius, it also works well with JRuby.
It comes with a simple, yet significant configuration option set to adapt the web server both for production and development needs in many ways.
Although Puma does not directly support hosting multiple applications out-of-the-box, it has Jungle: a (Puma as a service) tool to help with the production needs of multiple applications.
Thin: Tiny, Fast, & Funny HTTP ServerThin is a very popular application server which claims itself to be the most "secure, stable, fast and extensible Ruby web server". Still actively developed, it is based on, and hence the product of, three decisive Ruby libraries:
NotesThin HTTP server is designed to work with any framework implementing Rack specification, which covers the majority today. It does this by loading Rack configuration files directly.
Being an Event / Machine based application server, Thin is capable of handling long running requests unlike some other choices without the help of a front facing reverse-proxy solution.
Unicorn: Rack HTTP Server for Fast Clients and UnixUnicorn is a very mature [Ruby] web application server, so much so that it was adapted to be used with Python as well. It is fully-featured, however, it denies by design trying to do everything: Unicorn's principal is doing what needs to be done [by a web application server] and delegating rest of the responsibilities to those which do them better.
NotesUnicorn's master process spawns workers, as per your requirements, to serve the requests. This process also monitors the workers in order to prevent memory and process related staggering issues. What this means for system administrators is that it will kill a process if (for example) it takes too much time to complete a task or memory issues occur.
As mentioned above, one of the areas in which Unicorn delegates tasks is using the operating system for load balancing. This allows the requests not to pile up against busy workers spawned.
Much like NGINX, with Unicorn you can perform and deploy your applications (think of updates/upgrades) without dropping alive connections and clients.
Some of its other advanced features:
There are no attachments for this article.
How To Use SuExec in Apache to run CGI Scripts on an Ubuntu
Viewed 1494 times since Mon, Dec 30, 2013
How To Manage Packages In Ubuntu and Debian With Apt-Get & Apt-Cache
Viewed 865 times since Fri, Dec 27, 2013
How To Install Node.js with NVM (Node Version Manager) on Server
Viewed 1575 times since Sun, Dec 29, 2013
How To Create, Remove, & Manage Tables in PostgreSQL on a Cloud Server
Viewed 1665 times since Mon, Dec 30, 2013
Upgrading Debian to Unstable
Viewed 1527 times since Thu, Dec 26, 2013
The Basics of Using the Sed Stream Editor to Manipulate Text in Linux
Viewed 826 times since Fri, Dec 27, 2013
How To Install an Upstream Version of Node.js on Ubuntu 12.04
Viewed 984 times since Sun, Dec 29, 2013
How To Set Up Apache Virtual Hosts on Debian 7
Viewed 1145 times since Fri, Dec 27, 2013
How To Use Dokku Plugins to Access Additional Functionality
Viewed 2581 times since Sun, Dec 29, 2013
How To Install and Use Memcache on Ubuntu 12.04
Viewed 1129 times since Tue, Dec 24, 2013