Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter switches from Mongrel to Unicorn

engineering.twitter.com

Post reply on HN
Print view View original

1–10 of 19 posts

Re: Twitter switches from Mongrel to Unicorn

#2

Post by wglb »

This is a good engineering discussion. At the core of it is what we used to call back in the 70s doing real-time medical work "multiple server queues" versus "multiple queues each with one server". The different performance implications of each of these was pretty well known well before we studied it. The reference book we used as I recall was "Real-Time Data processing" by Stimmler (maybe also Robert Martin of Robert Martin fame).

Re: Twitter switches from Mongrel to Unicorn

#4

Post by ck2 »

For a moment the name made me think it was an early april fools but that turned out to be very interesting.

These days however, almost anything is faster and more stable than apache under load. It's really starting to show it's age unfortunately.

(and darn I wish we had a Fry's here!)

Re: Twitter switches from Mongrel to Unicorn

#5

Post by anotherjesse »

wglb wrote: post #2

This is a good engineering discussion. At the core of it is what we used to call back in the 70s doing real-time medical work "multiple server queues" versus "multiple queues each with one server". The different performance implications of each of these was pretty well known well before we studied it. The reference book we used as I recall was "Real-Time Data processing" by Stimmler (maybe also Robert Martin of Rober…

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?

Re: Twitter switches from Mongrel to Unicorn

#8

Post by ssp »

Shopping is even more efficient if you distribute all your items across all the cashiers. That way, the time from you are first in line until you are done, is n / num_cashiers instead of n.

Someone, please try this the next time you go shopping, and then blog about what happened.

Re: Twitter switches from Mongrel to Unicorn

#9

Post by generalk »

Is there some technical reason I'm missing for why they wouldn't go the Passenger route? Seems to be by-far the easiest way to deploy a Rack-capable web app, and it (correct me if I'm wrong) allows for "hot deploy": update the code on the server and it'll sit there unused until you touch "tmp/restart.txt" under your app root.
Post reply on HN