How Many Mongrels?

On Rails production performance and monitoring

How Many Mongrels?

Published on October 28, 2008 by mark

So your shiny new Rails application is ready for production. Time to configure the server application layer. A common question we hear at FiveRuns is: What’s the best number of Mongrels to use? There are a plenty of opinions, including yours, so feel free to comment below.

Test Drive

Early on, Zed recommended performance testing with httperf and an increasing numbers of mongrels to determine the best number for your setup. Test a file served directly from the web server and then test your app via a single mongrel instance. This provides a static file reality check and then a decent baseline from which to improve the responsiveness based on additional mongrels.

> 1

Depending on the memory footprint of each mongrel process and the available system memory, you may have an upper limit to consider for your server. Some administrators use at least two mongrel processes to balance the queue and avoid any locking behind a single mongrel or Rails request. My tests with a very entry level 256 MB virtual machine yielded the best performance using 3 mongrel instances behind an Apache2 front end.

Us

The average number of mongrel processes used by our customers is 5 per Rails app and 12 per server on systems with 8 GB of physical memory. This is what we run here at FiveRuns too. For example, a common setup is to have two high volume applications, served by 5 mongrels each and a lower volume Rails app with 2 mongrels. A lightweight front end like nginx balances traffic among the mongrel ports in use and optionally, any additional application servers in the hardware pool.

None?

Choosing not to answer the “How many Mongrels?” question is becoming a popular option. Passenger handles the port management between the front end and application layer, including the optimal number of back end processes. Thin is lightweight and crazy easy to install and configure. Each yield comparable or better performance metrics. Ebb also lists significant performance gains over mongrel.

So with configuration ease and performance gains, why choose mongrel today? Still grateful for delivery from FastCGI/lighttpd? (like me?) Perhaps you are gauging the community adoption of the alternatives? Maybe it’s a proven part of your existing architecture?

Permalink

Continued Discussion

4 responses to this entry

I always try to run at least 2 mongrels per app in order to prevent any deadlocking and queuing issues. monit usually responds and kills a locked mongrel process before both get locked.

For less frequently used apps, I’ve found Passenger to be great. It takes several seconds for the app to spool up from a cold start but it saves a ton of resources on my servers.

Right now my production server has 4 mongrels, Apache, Passenger hosting 4 apps, MySQL, and email hosting all barely within 1 GB. A lot of this is possible because most of the apps cache the heavily trafficked content.