inline... -Michael http://javathehutt.blogspot.com
On Mar 9, 2007, at 7:07 PM, [EMAIL PROTECTED] wrote: > > On Mar 9, 6:22 pm, "Rob Sanheim" <[EMAIL PROTECTED]> wrote: > >> Is ~4 mongrels per core a normal baseline you start with for hardware >> like that? A site I'm working on will have a simliar setup -- 3 web >> servers with dual dual-core xeons, though with less ram (4 to 8 >> gigs). >> This would be behind Apache, though, would that change the >> recommendation of 4 per core? > > There's a general understanding in Unix performance tuning that a load > of 4.0, which means that at any moment in time there are 4 processes > running or waiting to be scheduled (i.e. in the run queue), is > considered > saturation. > > This is a *very* indirect measurement of exactly what is going on in a > system and assumes that those processes are CPU bound, and not > bound on other things such as network I/O, disk I/O, etc. > > So, very simplistically speaking, a good place to start in just about > any > tuning project is 4 running processes per core. Again, this is an > *ultra* > simplistic way of looking at things. > > In a typical Rails deployment scenario, the front-end web servers are > highly unlikely to break a sweat compared to the back-end application > servers. Since we're talking about such a rough measurement and only > a place to begin tuning at, I literally wouldn't even consider the > front > end processes into this equation. > > If MySQL is running on the same box, however, that would figure into > the equation. > Assuming the scenario with everything running on one box can you elaborate about how MySQL would figure into the equation? At the moment it seems like maybe RAM would be the only factor because ruby seems to be the CPU bottleneck by a long shot. I can't really even get MySQL to blink. From my testing thusfar (granted not as extensive as I'd like or as you and Ezra have no doubt performed) I don't see how in a single box environment tuning anything other than the web server process count and ruby/rails is going to make any perf diff. Just curious if I'm way out of line with that thinking. I'm basing my observation on my log file time division where 80-90%+ is spent in ruby compared to 10% or less for MySQL. > Unix system performance tuning is a very complex subject, and it > changes all the time. That said, some of the best books written on the > subject were written a long time ago, when resources such as CPU > cycles, RAM, and disk storage were all scarce and expensive. > > Here are two of the best books I've ever read on the subject, and > would highly recommend everyone interested in deployment read: > > http://www.oreilly.com/catalog/spt/ > Thanks for the book recommendations... TIme to go see if it's in safari so I can read it online :-) > I'd also recommend a book by Adrian Cocroft, which I believe was > called Solaris Performance Tuning. I'm *shocked* to find almost > zero references to that book in Google. It was a really great book. > > If it's out of print, it makes me want to run to my bookshelf and > make sure it's still around, because it's a really great book. :-) > > -- > -- Tom Mornini, CTO > -- Engine Yard > Best, -Michael > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
