On 30 May 2011, at 20:12, Yiannis wrote:
I bought a new server and I was wondering what application server is
the best choice for a typical web application with rails.
I’ve thought for a long time that the best choice was apache/nginx and
phusion passenger but nowadays I am hearing a lot about thin and
unicorn. I have used passenger a lot and to be honest, even though
passenger is very easy to setup, wasn’t so great. What is your
What was “not so great” about Passenger? For us it’s serving high
volumes with great ease and performance.
For your typical Rails application, Passenger will be the best choice
(with ruby enterprise edition). It’s easy to setup, it spawns new
instances when it needs to, kills them when they have been idle for a
Both Thin and Unicorn work behind a load balancer (whether that’s
Apache’s or HAProxy or doesn’t really matter all too much). It’s up
to you to decide beforehand how many instances you expect to be needed
to run and they will all be running all the time.
Now, there are valid scenarios where you could consider using Thin or
Unicorn over Passenger.
Thin, being an evented server, is simply so much better than Passenger
when you’re using gems like EventMachine. Not that it can’t be done
with Passenger, but you’ll need to be very careful with spinning down
the reactor on despawn, firing it back up again on every new instance
spawn and spawning a new instance usually takes a bit longer too.
Unicorn is great for fast clients, but falls dead in the water with
slow clients (Rainbow claims to solve this more or less). So when
using Unicorn, you need to be 100% sure you will be dealing with low
latency clients (i.e. no mobile, no keepalive sockets etc). It really
should be: request, response, spit it out.
The gist of this whole reply is that you should determine for your
application which application will suit it best and what your personal
preference is (yeah, that also comes into play quite often :-)). We
use Passenger for just about everything, but also have one or two Thin
servers running for legacy apps that run under a different Ruby version.
Peter De Berdt