Comments on: Thin vs. Mongrel: A Ruby on Rails performance shootout

By: science

science — Fri, 06 Jun 2008 17:45:10 +0000

Woody: Ezra is one of my main sources on the idea that nginx should not proxy across multiple machines. Their model is to put a set of Linux-based load balancers in front of a bunch of machines all running identical stacks of nginx/mongrel/rails.

The problem with this model as best I can see it is that you have to have either an event-driven queue on the front-end LB’s or you have to have identical performance/power on the nginx boxes and a very consistent response time on your various web pages. If one nginx box falls behind it will be loaded up with additional requests that it will have trouble clearing in a timely manner, while other nginx boxes may actually have free cycles.

I hope this helps a bit.. - S

By: Woody

Woody — Fri, 06 Jun 2008 17:13:14 +0000

I’d be interested to know the reasoning behind that. Ezra Zygmuntowicz of Engine Yard has been advocating separated nginx/mongrel machines for the benefit of identifying individual performance problems (I believe that’s the idea, see http://www.slideshare.net/vishnu/xen-and-the-art-of-rails-deployment/ page 32 and 35). However, I can also imagine that something like ultramonkey would be very good at load balancing requests, which nginx isn’t specifically made for, so you could put that in front of a bunch of nginx/mongrel/rails boxes and the relative computing overhead of nginx to a cluster of local mongrels would be negligible, no? I have always thought this, but only heard that it was a better practice to separate them. Could someone elaborate?

By: science

science — Sat, 31 May 2008 18:24:16 +0000

m++: I have heard some credible people say that it’s unwise to let nginx proxy across multiple machines. It’s better if possible to have nginx serve only mongrels on the OS where it’s running and to put a set of load balancers in front of your cluster of web boxes running nginx/mongrel/rails to smooth things out. The downside of this is that you can get somewhat uneven load across your servers in some circumstances.

By: m++

m++ — Fri, 23 May 2008 03:17:51 +0000

RE: mongrel optimization — i meant to say the HTTP parser is written in tight C.

By: m++

m++ — Fri, 23 May 2008 03:16:37 +0000

I realized recently that the 4% can be entirely explained by the difference between unix and IP sockets. There is another study proving this out with nginx + mongrel vs. fastcgi. Basically, the unix sockets are faster but at the expense of potential horizontal scaling which mongrels allow because they can be on different machines than the nginx. I looked at the mongrel source, and it is pretty nicely optimized. It starts with an HTTP parser and then drops control into a ruby thread pool. Using a Mongrel::HttpHandler subclass and setting the thread pool to 1000, you can get really high concurrency. Rails locks each mongrel however so for that configuration the number of concurrent users is 1:1 to the number of mongrels.

By: daeltar

daeltar — Sun, 20 Apr 2008 23:10:06 +0000

it would be nice to have numbers about RAM usage

By: m++

m++ — Thu, 17 Apr 2008 03:34:32 +0000

4% is good, but it’s also not much. I guess we’ll stick with mongrel_cluster and look for more fundamental optimizations in our code, queries, and database setup rather than undergoing the configuration pain of switching over…