Production Rails Tuning with Passenger: PassengerMaxProcesses

http://blog.scoutapp.com/articles/2009/12/08/production-rails-tuning-with-passenger-passengermaxprocesses

by itsderek23 • 17 years ago

14 4 17 years ago

blog.scoutapp.com

jeremyw2• 17 years ago

Generally speaking, you want to fill up as much RAM as possible with passenger processes without utilizing swap in order to maximize you performance and throughput.

Uh, what?

On a single-app box with real traffic (as the article implies), look first to CPU. If your average request spends 50% time in db/services and 50% time in processing/render, using more than 2-3 passenger procs per core (i.e. 100% core utilization) is less efficient and a waste of memory. Multiply by cores. (Back off a bit for db on the same machine.)

You want plenty of spare memory for OS cache, to keep your code and static files in memory -- that is, your disk reads should be zero.

And don't do swap, kids.

jnewland2• 17 years ago

Excellent point, Jeremy. This article didn't talk at all about the CPU/RAM balance, which is a important to consider when scaling any application. In my experience, a large number of Rails apps are more RAM bound than CPU bound due to large gems/libraries/codebases.

Having additional Passenger processes available even when CPU bound will allow for greater throughput (if at a less-than-ideal speed) than having requests back up on the queue, however - especially if those requests spend a good amount of time waiting on DB, memcached, or other external API calls.

jeremyw2• 17 years ago

If you're CPU-bound, you can't have greater throughput, by definition. Once you calculate your non-cpu latency (50% in my example) ceil(1/latency%) is your limit per core, before you start wasting resources.

Production Rails Tuning with Passenger: PassengerMaxProcesses

Related Stories