Production Rails Tuning with Passenger: PassengerMaxProcesses

blog.scoutapp.com

14 points·itsderek23··4 comments

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.

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.

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.

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.

Reply on news.ycombinator.com