Thin vs unicorn vs passenger

rubyonrails-talk
#1

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?

#2

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

#3

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

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 deployment - Slow initial server startup when using Phusion Passenger and Rails - Stack Overflow), 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?

#4

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,

#5

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