Re:Production Rails Tuning with Passenger: PassengerMaxProce...
by jeremyw on Tuesday December 08, 2009 @02:22PM
(#984391)
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.
Re:Production Rails Tuning with Passenger: PassengerMaxProce...
by jnewland on Tuesday December 08, 2009 @02:40PM
(#984434)
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.
Re:Production Rails Tuning with Passenger: PassengerMaxProce...
by jeremyw on Tuesday December 08, 2009 @02:51PM
(#984464)
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.
Re:Production Rails Tuning with Passenger: PassengerMaxProce...
by jnewland on Tuesday December 08, 2009 @03:25PM
(#984541)
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.
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.
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.