As some of you may have heard, Rails 2.2 is going to be thread safe. This was pretty exciting for us as we’ve been struggling lately with memory issues running Mongrel clusters in virtualized environments, where memory is scarce and those Mongrel processes are pretty big.
While some have pointed out limitations of MRI due to green threads and certain commonly used libraries, and others are super-excited about what this means for JRuby, we were very curious about how Mongrel would perform serving Rails requests concurrently on MRI, which is very close to our/the standard Rails deployment.
As it turned out, Mongrel was pretty easy to work with, and initial tests suggest we were able to see a huge drop in memory usage while getting comparable performance to a Mongrel cluster. I haven’t included numbers as this was really more of a proof-of-concept spike and others will no doubt run with that, but we’re happy enough that we’ll be moving an app or two to edge shortly to see how well they perform.
A patch for Mongrel is pending feedback from the Mongrel team, but for now if you’re curious you can grab the source and run your own threaded Mongrel (on edge Rails) like so:
mongrel_rails -N X -n Y
where X is the number of concurrent requests Rails should process (active Rails threads) and Y is the number of concurrent requests before Mongrel starts refusing connections (standard Mongrel num-processes). Note: run one process per-core or turn off a core if you want to compare performance to a Mongrel cluster.
Feel free to provide feedback in comments, or on the mongrel-users mailing list.
About the Author
