Thin vs Unicorn on Heroku

Question

Just wanted to get people's opinions on using Unicorn vs Thin as a rails server. Most of the articles/benchmarks I found online seem very incomplete, so it would nice to have a centralized place to discuss it.

Unicron is a multi-processes server, while thin is an event based/non-blocking server. Event-based servers are great... if your code is asynchronous/non-blocking - vanilla rails is blocking. So unless you use non-blocking rails libraries, I really don't see the advantage of using Thin. Even worse, in a non-blocking server, if your i/o loop is blocking you're going to block the entire loop and not be able to handle any more requests until the blocking call returns. Blocking libraries are going to slow thin down!

Why did Heroku choose Thin as their default server (for cedar)? They are smart guys, so I'm sure they had a reason.

Bellow is a link that suggests replacing Thin with 4 Unicorn workers - this makes perfect sense to me. 4 Unicron workers on Heroku

Answer 1

Thin is easy to configure - not optimal, but it just works in the Heroku environment.

Unicorn can be more efficient, but it needs to be configured: How many workers? Preload App? What do you pick?

I have released Unicorn Heroku apps with workers set to 3, 5 and 8 - just based on how big each app is - how much code, how much memory is used and how much traffic you get all go into picking this number, and you need to monitor over time to make sure you got the number right, and your app isn't running out of memory.

Preload false - this will make your app start slower, but when Unicorn restarts a worker, this is 'safer' with network connections (memcache, postgres, mongo etc)

Preload true - this is better, but you need to handle server re-connections correctly in the pre and post fork code.

Thin has none of these issues out of the box, but you only get process of execution.

Summary: It's really hard to configure Unicorn out of the box to work well (or at all) for everyone, whereas Thin can just work to get people running with fewer support requests.