YARB

A few commenters are right to point out about the previous article that 6 requests per second (550k in a day) doesn’t seem like all that much. Very true, indeed.

So, what’s the point?

Lots of people wonder if Rails will “scale” – as if there’s a single magic bullet to scaling.

The more accurate question people should be asking is, how much will it cost to scale?

Anyone can scale a site by throwing $10,000 Sun boxes at the problem on dedicated T3 lines. The real goal is to scale efficiently, economically and as linearly as possible.

Google’s solved this problem rather nicely—they scale using commodity off-the-shelf hardware. If they kept having to buy $20k boxes, then $50k boxes, then $100k clusters, each time they needed to expand, then the entire premise of their search business would crumble as their profit margins dwindled.

550k in Perspective – CPMs

There’s no advertising on Incredimazing – but other content sites that I operate, which do have advertising, obtain roughly $3 CPMs.

That’s ~ $3 for every 1,000 pageviews. Of course these visitors are coming from Google and all over the place, not Digg. (social media site users are notoriously anti-advertising)

So let’s say we get our $3 as usual CPM on some monster traffic site that we’ve eventually built up to 550,000 pageviews per day.

That’s $1,650 in revenue per day or $49,500 per month. Our $400 server could accommodate this nicely as we’ve seen, costing us only ~1% of our monthly revenues.

More than 6 Requests / Second

It should also be noted that the traffic was very ‘bursty’—probably about 300k of it came over the course of several hours, just as it hit the front-page and then for several hours after that. So the 6 requests per second figure is actually lower than it was in reality.

Update 3/24/08: Fark/reddit strikes, resulting in a 920k pageview day (same setup, just 7 mongrels).

Update 1/13/08: The site was on Digg again; this time receiving 450k views over the course of just 12 hours. Brings it up to 12 requests / second. Again this is not a benchmark, just the actual traffic. CPU usage was never a problem; more than likely the app is RAM bound. Oh and the $400 servers handle many other sites. To me, it’s more important not to have to think about servers, rather then pinching pennies in an attempt to squeeze every last ounce of performance out of machines. Just my $.02.

Over the weekend, this New Christian Science Textbook comic made it to the front page of Digg.

The above traffic graph should give you a sense of the kind of traffic that Digg can drive. It was front-paged sometime early Sunday morning. Chances are, if it hit during the middle of a weekday, the stats would be as much as 30-50% higher.

As you can see, roughly 550,000+ pageviews were logged over the course of 24 hours. Had this been over the course of 2-3 hours, the Incredimazing servers surely would’ve been crushed under the load.

Update note: had it been necessary, which it was not, enabling Rails Page Caching (see below) would have rendered the entire scalability question moot. nginx would’ve become the server from stack to stack for many pages—it’s been benchmarked at 250 to 330 requests per second (10M+ per day) which was clearly unnecessary in this case anyway.

Still, people are always (and probably will always) be wondering, can Rails scale?

The answer will always be amorphous, but at least I can give you some cold hard facts as to withstanding a digging of this nature.

The Hardware

The domain is hosted at LayeredTech on a dedicated two-server (DB + Web/App) setup. Several other sites can comfortably be hosted all on the same setup. The total setup runs about $370 per month.

Web/App Server

• Cost: $127 / mo.
• CPU: Intel P4 – 2.8GHz
• Memory: 2GB
• Bandwidth: 1500GB (the box rarely uses more than 25% each month)
• Uplink Port: 10Mbps
• Hard drive: 80GB x2
• OS: Fedora Core 4

DB Server

• Cost: $242 / mo.
• CPU: AMD Single CPU Dual Core Athlon 3800
• Memory: 2GB
• Bandwidth: 2000GB
• Hard drive: 500 GB x2 in SATA RAID 1
• Uplink Port: 100Mbps
• OS: CentOS 4.x X86_64 Bit

Both have dual NIC cards and are connected across a private switch.

Software Versions Used

• Ruby: 1.8.4
• Rails: 2.0.2
• MySQL: 5.0.27 standard
• nginx (web server): 0.4.13 (built by gcc 4.0.2)
• mongrel: 1.0.1
• mongrel_cluster: 0.2.1

nginx – the Little Webserver that Could

nginx is a fantastic little web server developed by Igor Sysoev – and despite taking a hammering like this one, its memory usage rarely got above 10-20MB (total).

If you’re still not convinced (not that I’m trying to win converts here), Ezra Zygmuntowicz, author of Deploying Rails Applications, recommends it highly (and uses it extensively at EngineYard ).

Of course, Apache 2, Lighttpd, etc. would most likely have been able to handle the load similarly, so long as they were setup / configured / etc properly.

Rails 2.0 – Better ActiveRecord, etc. Performance?

I have no scientific evidence supporting this, but since making the switch to Rails 2.0, my sites have seemed a lot more stable and zippy. (this blog excluded – it sits lower on the totem pole!)

I believe some benchmarks of Rails 2.0 have shown some modest improvements over 1.0. My recommendation: update early & often—in about a day several of my sites were converted over to 2.0 with minimal issues.

Mongrel – The Legacy of Zed Shaw

1/24/08: Hmmm… the rest of this article must’ve been nuked somehow while editing it in Mephisto. Sorry!