Rant: I wish technical sites would stop using req/day as a metric. It leads to the op type of analysis. At the very least, such articles could use a format of "X req/day peaking at Y/s". Maybe if the NYT was writing it would be ok to use req/day but a sight who's tagline is: "High Scalability Building bigger, faster, more reliable websites." should know better.
(You can't save the sixth server if you want your site to be up while the seventh one is rebooting or being replaced.)
If the other comments are to be believed, this site was built by one person, working part-time, in four months. He can't afford to lavish time on unimportant problems, like desperately trying to conserve server resources that he could otherwise afford and that cost far less than a programmer's time is worth.
Of course, you're also totally throwing away the "new agile" platforms, like django, scala lift, and so forth.
2.5 of our physical servers run Passenger/Rails.
If this were a Java app, I definitely would have been able to get away with less (mostly because of less memory consumption, but less CPU consumption wouldn't hurt either)
However, I'd probably still want 2 machines for redundancy.
http://programming-gone-awry.blogspot.com/2009/06/how-to-sav...
10 million server requests per day sounds kind of impressive, until you actually do the math.. divided by how much physical iron they're using, that's a little less than 9 requests per second per server.
It makes me wonder: if they were using something other than rails, would they need that much iron?