Every millisecond counts. As professionals from industries outside the technology sector turn to web apps to run their businesses, shaving a minuscule amount of response time from your process can mean the difference between keeping an end user happy and losing their company’s account. It’s fair game to expect your Rails server to handle load balancing, to deter DDoS attacks, and to manage your app’s reverse proxy requests.
Selecting a Rails server can set the pace for your app’s speed and scalability down the road, and switching horses mid-stream can lead to some tough client conversations. Even as hardware gets more robust and cloud computing platforms aim to replace dedicated servers, three of the most popular Rails server products got major updates in the past few months. Therefore, we set out to compare Passenger, Unicorn, and Puma to see if there’s more than a slight difference in performance.
Passenger still gets the Rails Core Team’s vote as the “preferred way to deploy your Rails applications,” according to Phusion’s website. After a significant update during the summer, this popular Rails server now comes in two flavors: open source and Enterprise. This popular module directly integrates with Apache or NGINX, so you can upload and run your application code with ease.
Thanks to built-in deployment error resistance, Passenger can shut down all application processes when it encounters a configuration error or a glitch in an application’s code. The Enterprise edition of Passenger enables enhanced monitoring and debugging, so you can get to the source of an error in real time. An accepted standard for many corporate server environments, Phusion’s website boasts of over 150,000 leading companies running apps with Passenger.
When James Pozdena benchmarked Unicorn in 2009, it maintained consistent average response times of around a second, even when hammered by concurrent requests. Podenza noted that Passenger’s maximum response time grew by as much as a second with each concurrent request.
However, Urban Influence’s Nate Miller discovered that Unicorn’s speed comes at a cost. While testing Unicorn as a replacement for a Mongrel deployment experiencing a high number of 502 Bad Gateway errors, Miller benchmarked a similar drop in average response time on Unicorn. However, Unicorn’s standard deviation for gateway errors increased significantly, raising concerns that the speed gains could leave the door open to increased instability.
Evan Phoenix took a “Back to the Future” approach to rails servers, rewriting code from Mongrel that hearkens back to what Phoenix calls a “pre-rack world.” His benchmarks show Puma using less than one-tenth the active memory of a similar Unicorn setup, while trouncing competitors in speed tests. Puma leverage’s Mongrel’s heritage HTTP parser, offering accuracy without the “stuck mongrel” issues that dogged early Rails deployments.
Puma runs best with Rubinius or JRuby, implementations that provide true concurrency. As developers prepare for Rails 4, some admins report significant speed improvements when combining Puma with NGINX’s proxy functionality. As recent Ruby converts search for Rails servers, developers have noticed the difference between a slow stack and a system supercharged with Puma.
Even though Passenger’s recent updates address both speed and stability, Puma offers a lean and fast web server solution for most applications that require high concurrency. Of course, it always makes sense to run your own benchmarks and application tests. However, with growing support for Puma on many cloud-based application servers, this significantly refreshed version of Mongrel should be easy for you to test and to enjoy.