
Backslapping Ruby’s average performance once again - nickb
http://codehappy.wordpress.com/2008/07/19/backslapping-rubys-average-performance-once-again/
======
iloveyouocean
The application, BumperSticker, simply serves out customized images to users -
online bumper stickers

The vehicle, Space Shuttle, simply carries a payload a few miles off the
surface of the Earth.

The author gives no basis for comparison, what would the identical app in
Python require for hardware? Also, the app does more than just serve up
images. It seems that the most common experience with RoR is that it is less
performant than other Languages/Frameworks, but this article can hardly be
considered proof of that.

------
ericb
Let's see, 12 of the machines are database and web server machines. Here's a
hint--ruby doesn't make you need particularly more or less web servers or
mysql machines. The fact that the author bemoans this betrays that he doesn't
especially understand what he's talking about.

They are serving around 3/4 of a billion page views a month. That's billion
with a B. So yeah, I'd give them a slap on the back for that. Would it be
cooler if they needed 9 app servers instead of 13--sure, but come on.

~~~
tx
Instead of hundreds per second I see you've switched to billions with a "B"
per month? No shit, Sherlock. How about Trillions with a "T" per year? You
should also try measuring shit in football fields just to make your arguments
more impressive.

~~~
ericb
Backing into per-second transactions from larger numbers is far more suspect,
Holmes. Those transactions _could_ be spread out perfectly evenly over the
course of a day (hint: not likely), _or_ 80% of that traffic might come in a 6
hour window in a pattern shaped like a bell.

------
matthewking
It's not very likely that the 27 million requests per day was divided entirely
evenly over the 24 hours. Assuming lows and highs, those requests could well
exceed 1000 requests /sec at peak times.

The data is really open to interpretation, which would allow you to draw any
conclusion from it, unless a more detailed breakdown of lows/highs was
provided.

------
jm4
Wow... The amount of hardware required for that application is just
horrifying...

I'm really not sure what to think of this. I know Ruby isn't a speed demon,
but 25 servers to serve up a few hundred images per second is just insane.
These articles about scaling Ruby/Rails apps remind me a bit of those old
Java/EJB/SuperEnterpriseEdition/TimeSink hello world examples that took 80+
lines of code... only with hardware.

I'm not a big Ruby fan, but I have a hard time believing that this is
representative of the experience one could expect to have scaling a Ruby
application. Can anyone here share some personal experience? All that seems to
be out there is the typical Twitter bashing kind of stuff.

By the way, I think this is the article the blog refers to:
<http://blog.linkedin.com/blog/2008/06/web-scalability.html>

~~~
blader
They're not just serving up images - hundreds of thousands of images are being
uploaded daily and millions more are being sent to different users every day.

It's not like a blog or digg, or even YouTube where you can just serve up
static files for the most part. Social applications tend to be extremely
write-heavy and every request ends up hitting the full Rails stack.

We do around 1/3 of a billion page views per month and we run on about half of
those machines. [http://highscalability.com/friends-sale-
architecture-300-mil...](http://highscalability.com/friends-sale-
architecture-300-million-page-view-month-facebook-ror-app)

------
jrockway
People seem to like blaming Rails for things that aren't Rails' fault. The
stuff that's probably using CPU time is actually generating the image. Getting
the data from the user and into the database via a CRUD interface probably
doesn't require that much hardware. If it did, that would be a joke, but I
doubt that's the problem. (Just like Twitter's problem isn't reading the "What
am I doing" form submission and adding it to the database. The hard part is
what happens _after_ that, way outside of Rails' control.)

As for the large number of static image servers, that again has nothing to do
with Rails.

Anyway, I doubt changing languages would fix the problem. You'd still
bottleneck on MySQL (for extracting data), and generating images (since every
language uses the same image libraries; all written in C anyway).

In conclusion, without some more data, the author is clueless.

------
jdelsman
Taking the other side for a moment, I think things like EC2 and S3 could help
mitigate some of the costs of scaling RoR apps like this. Thought out prior to
making rash decisions like buying dedicated servers from Joyent at a high
cost, you could possibly save your company quite a bit of cash.

However, I do agree that Ruby (and Rails) needs to get its act together. Sure,
its never going to be the best, but the ease of development and deployment and
(etc.) makes it very, very hard to turn down.

BTW: 25 servers to service up to 400 images per second is inaccurate. It only
took them 8 asset servers to serve that amount of images. Even so, that is
pretty ridiculous. I would have to say that they didn't spend time optimizing
their asset servers, or anything else other than Ruby. I think it could be
done better.

------
henning
This assumes that when scaling up a Rails application, Rails itself is the
bottleneck rather than, say, the database.

Honestly, I just find that hard to believe.

If the author wants to write another "gosh, relational databases aren't always
perfect for every situation" article, get in line.

~~~
jrockway
Well, the 13 app servers aren't bottlenecking on the 4 database servers. If
the database was the problem, you wouldn't need 13 app servers.

~~~
ericb
Yeah, but as stated elsewhere, image generation is CPU intensive and there's
no indication what drives the need for the app servers. Armchair
quarterbacking is fun for the whole family. Let little johnny tell you why
your app doesn't scale!

------
gunderson
Welcome, Redditors, to news.yc!

Let the flame war about Rails begin!

