FiveRuns Blog

On Rails production performance and monitoring

Posts
1 comment

How Many Mongrels?

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?

Bookmark and Share
Continued Discussion

1 response 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.

Eric Davis Eric Davis said:

on October 28, 2008 at 07:52 PM

Contribute

Continue the conversation and share your thoughts. A name is required. Your e-mail address will not be displayed on the site. Textile formatting may be used in your comments (but will not be rendered in the live comment preview).

→ Posted by You on December 15, 2008 at 04:45 PM

Flickr

FiveRuns tagged photos on Flickr.

  • FiveRuns at the SF Ruby User Group
  • Mike
  • FiveRuns at the SF Ruby User Group
  • The office
  • FiveRuns at the SF Ruby User Group
  • FiveRuns at the SF Ruby User Group
  • FiveRuns at the SF Ruby User Group
  • Mindy

See more FiveRuns tagged photos…

Previous Entries

Other Categories

Entries are also organized under the following general topic categories.