infotage.net

Not that I have a high traffic ruby on rails site yet but the time will come and I want to try and set it up well from the start. The main problem is that ruby on rails is not thread-safe so each request must be handled by a separate process. So generally that means a backend which is conventionally (if that term can be used for discussion on techniques used in the last few months) fastcgi or mongrel/mongrel_cluster. The front end is then generally a load balancer between these. Sometimes there is even a 3rd software component in there somewhere. So the approach that has become popular that I was thinking of using was apache 2.2 with mod_proxy_balancer and mongrel_cluster. However I came across a really significant problem while reading up on this today.

The problem was articulated on the mongrel_users mailing list in an email entitled Why Rails + mongrel_cluster + load balancing doesn’t work for us and the beginning of a solution. The problem is that many load balancers choose poor algorithms to balance requests which can become a problem if the requests vary in the amount of time they take to complete. A round-robin algorithm, for example, could place a show request on one process, and then place another one the next trip around despite that process still being busy while others are available. The solution is that only 1 request at a time can be sent to each backend process for ruby on rails. If all processes are busy then the request should be queued for the next available backend process. Now reviewing the apache 2.2 docs about the ProxyPass Directive it seems like apache has some options to address this. It would be worth testing the various options before going to another solution such as writing another balancer for apache method as suggested here and here or adding another load balancer such as haproxy, nginx, pen, pound, lighttpd, etc.  I also think that this test case would be en excellent way to benchmark various ruby on rails setups absent of a working app as compared to the case used in this comparison: Looking For Optimal Solution: Benchmark Results Summary and Findings.  If nothing else this highlights the need to be very aware of the configuration of the web setup to run ruby on rails applications.

1 comments so far

"Yet another post on how to setup Ruby on Rails to deal with high traffic websites" was written on January 15, 2007 and filed in all, ruby on rails