Backslapping Ruby’s average performance once again | Hacker News Reader

Backslapping Ruby’s average performance once again

codehappy.wordpress.com

7 pointsnickb14 comments

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.

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.

Most of us would definitely trade 3 servers for any appreciable shortening of time-to-market.

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.

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.

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.

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

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...

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.

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.

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.

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.

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!

Welcome, Redditors, to news.yc!

Let the flame war about Rails begin!

Reply on news.ycombinator.com