

Production Rails Tuning with Passenger: PassengerMaxProcesses - itsderek23
http://blog.scoutapp.com/articles/2009/12/08/production-rails-tuning-with-passenger-passengermaxprocesses

======
jeremyw
_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.

~~~
jnewland
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.

~~~
jeremyw
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.

~~~
jnewland
You can't gain any more cycles, of course, but you _can_ gain throughput by
adding processes to an already cpu-bound app by giving faster incoming
requests a place to go instead of sitting on the global queue while waiting
for other requests to process.

