Forum: Ruby on Rails Thin vs unicorn vs passenger

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
suggestions?

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
> suggestions?

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
while.

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.


Best regards

Peter De Berdt

Thank you very much for your answer! I have a better understanding now
about the new servers. :)

Currently ruby enterprise edition is in 1.8.7 and I prefer to use
1.9.2. My problem with the passenger is with the slow initial server
response time. I have tried many things (including all the
recommendations from here
http://stackoverflow.com/questions/853532/slow-ini...),
but I didn't see any significant difference.

That is basically the main issue with the passenger which I don't know
how to fix it and made me thinking of other solutions. If I use nginx
instead of apache, will this help with the problem?

Hi guys,

is anyone can help me with this thing? Actually, I have used this for a
couple weeks and it doesn't matter. Somehow, it suddenly gives me 
trouble.
My site used page cache, but I have removed it. I don't know what is
wrong with it, I have entered the correct code but it still not valid.

Anybody got clue? or maybe you have other suggestion for captcha things?

Thank you,

--
Hafiz Badrie Lubis

On 31 May 2011, at 13:19, Yiannis wrote:

> instead of apache, will this help with the problem?
No, the initial slow request is because no app instance has spawned
yet. So, when you restart your Rails app, Passenger kills off all
instances and the Spawner just waits until a request comes in. Only
then will it boot up your Rails app and start using memory.

However, some time ago Passenger introduced a new setting called
passenger_min_instances, which will keep at least the number of
instances you specify running. That should eliminate the slow startup
speed at the expense of guaranteed memory use even when an instance is
idle and not needed anymore.


Best regards

Peter De Berdt