[anotherjesse]

I thought the coverage was pretty weak. Not due to unicorn but because there are many options (including passenger (aka mod_rails) for apache) that allow queueing to occur at the proxy instead of at the individual workers.

I wish they had discussed why unicorn instead of mongrel and why didn't solutions like haproxy or passenger or ... didn't work?

This discussion was: our apache configuration didn't work so we switched the load proxy mechanics and our app server at the same time.

I've had great success with mongrels with HAProxy (with maxconns=1 so only 1 request per mongrel at a time) for years. I've also had great success at Passenger with apache.

I think it is a great step forward for twitter's servers, I just wish the article had some meat. Isn't this the twitter engineer blog, not blog for the general audience about how twitter works?

[teej]

(HAProxy + Mongrel) and (Apache/Nginx + Passenger) work great. Don't get me wrong, I've seen lots of different Rails server architectures and I've spoken at RailsConf on this very topic. I would recommend either setup to a Rails startup in an instant.

But in the edge case of immense load, they simply don't keep up to Unicorn.

The thing that sets Unicorn apart is that it does it's load balancing on the Kernel level. All Unicorn worker processes are listening on the same socket. The OS takes care of getting each request to a single, available worker. So unlike Mongrel, you don't end up with per-worker queues. Though HAProxy is smart about distributing load well, Unicorn makes it seamless. The workers simply ask for a new request and the Kernel gives it one.

There are some other niceties too. Unicorn processes are forked from a master process. If you are using REE, they can keep Rails in a shared memory. When we deployed it, we dropped memory usage by 30%.

On top of all that, Unicorn's flawless rolling restarts are a pretty big plus.

In conclusion, if you're in the top 10% of Rails apps by traffic, give Unicorn a look. It is likely that switching over is worth the dev risk and cost. Otherwise, keep it on your radar, but don't consider it a must-have.

[reference]

http://unicorn.bogomips.org/DESIGN.html

http://news.ycombinator.com/item?id=872283

[FooBarWidget]

(FYI I'm a Phusion Passenger developer.) I find it interesting that you think the shared socket performs better than letting a proxy distribute the load. I've also done some tests and I find that the shared socket harms performance on high concurrency situations because of the so-called thundering herd problem. The problem is that all Unicorn workers select() on the socket, but when a client comes in all workers are waken up, all of them try to accept() the client but only one succeeds, and the rest goes to sleep. We're working on some pretty heavy performance and scaling optimizations for the upcoming Phusion Passenger 3 and we've found that avoiding the shared socket gives us much better overall performance. It'll be nice if the kernel provides an interface for performing select() and accept() in a single atomic operation but until then I think the shared socket isn't that good.

From what I've seen so far, peoples' experiences with both Phusion Passenger and Mongrel/Unicorn can vary drastically. Some people noticed a huge response time drop and performance increase when they switch from Mongrel/Unicorn to Phusion Passenger, others experience the opposite. I guess it depends a lot on the server. Phusion Passenger has got some pretty heavy users though, e.g. the New York Times Obama real time election results page was running on Phusion Passenger. The Dutch national TV broadcasting organization is running all their Rails apps on Phusion Passenger and they get huge spikes of traffic whenever something is mentioned on TV.