Scaling Ruby on Rails (and related Slashdot article today)

Rails
1

I presume most people here read today’s article on Slashdot which had
some critique about Ruby and scaling to a large architecture. Though
the article didn’t seem to elaborate into specifics, I’m interested in
other people’s feedback and perspective on this.

I’m currently learning Ruby. One of the first questions I had (and
Googled for) had to do with scalability, for large enterprise-class
applications. I found a couple of articles, but haven’t yet tested
this in a lab setting. Then there is Parrot, which I’ve not used
yet.

Due to the growing popularity of Ruby and Rails, I would imagine this
would be of importance. Pardon if I’ve missed something (I have
searched, and am searching) - that being the case, URLs to articles
would be appreciated.

Also how would such any approaches differ from that of how JAVA scales
with VM.

Thanks!

2

On Sep 23, 12:16 pm, forrie [email protected] wrote:

Due to the growing popularity of Ruby and Rails, I would imagine this
would be of importance. Pardon if I’ve missed something (I have
searched, and am searching) - that being the case, URLs to articles
would be appreciated.

Also how would such any approaches differ from that of how JAVA scales
with VM.

Thanks!

I haven’t read the Slashdot article yet – I seriously doubt that
there’s any new information in it, however. Here’s my view of the
subject.

  1. The Ruby 1.8 interpreter, aka MRI, does have some bottlenecks in it
    that could be alleviated. Most notable in the context of Rails are the
    garbage collector and method dispatch.

  2. ActiveRecord also has some bottlenecks in it that could be
    alleviated. I’m not at all familiar with them, but there are folks on
    this list actively working on them and I trust that they will pipe up
    and respond, assuming that their work is open source.

  3. There are several alternative implementations of Ruby 1.8, pretty
    much all of which have improved Rails performance as a goal. The
    farthest along is jRuby, an implementation of Ruby on the Java Virtual
    Machine. The next farthest along is IronRuby on the Microsoft Dynamic
    Language Runtime, followed very closely by Rubinius. Parrot appears to
    have fallen behind, although I would hope a pleasant surprise will
    emerge from that camp.

  4. Finally, Ruby 1.9 is due out the end of this year. I haven’t seen
    any Rails benchmarks for it yet, but for other benchmarks, Ruby 1.9
    kicks serious butt.

So … watch this space … I’ll go read the Slashdot article.

3

On Sep 23, 1:16 pm, znmeb [email protected] wrote:

On Sep 23, 12:16 pm, forrie [email protected] wrote:

I presume most people here read today’s article on Slashdot which had
some critique about Ruby and scaling to a large architecture. Though
the article didn’t seem to elaborate into specifics, I’m interested in
other people’s feedback and perspective on this.
So … watch this space … I’ll go read the Slashdot article.

OK … I went to Slashdot and all I found was a pointer to a blog post
where the proprietor of CD Baby described how and why he moved from
PHP to Rails and back again.

But I didn’t see anything about scaling.

4

Rails is just a conventional architecture with a web front end and a
database backend. As with all such systems, the biggest challenge is
the
database layer. As usual, the key is to make the app read-heavy and
build
multiple readonly slaves. Brutally cut out all unecessary writes. For
example, if you’re using the db to log impressinos, clickstream, etc.,
that’s gotta go - either to a different db or using lazy logging (e.g.
syslog, udp fire and forget). [I posted earlier, haven’t heard back yet: Which is better: acts_as_readonlyable or mysql-proxy or other?]

In practice, the AJAX part of a Rails application (or any other web-app)
is
what can make or break scalability: If every click, drag, etc. leads to
db
updates and inserts (for example: resequencing a list by dragging and
dropping an element -> update for each element of the list), then
clearly
the app will not scale. On the other hand the AJAX layer could actually
help scalability by making such updates less frequently than a non-ajax
app.

m

5

On Sep 23, 2:46 pm, “Marc B.” [email protected] wrote:

In practice, the AJAX part of a Rails application (or any other web-app) is
what can make or break scalability: If every click, drag, etc. leads to db
updates and inserts (for example: resequencing a list by dragging and
dropping an element → update for each element of the list), then clearly
the app will not scale. On the other hand the AJAX layer could actually
help scalability by making such updates less frequently than a non-ajax
app.

It isn’t just the database interactions you have to watch out for with
Ajax. You also need to pay attention to

a. Network traffic, number and size of network interactions with the
server, and how these interplay with WAN bandwidth from the client to
the server. Now of course, everybody has at least 10 mbits download
and 768 kbits upload speed that uses your app. :slight_smile:

b. Client-side processor and RAM resources. Now of course, everybody
has a 2 GB dual-core 2 GHz PC that uses your app. :slight_smile:

In short, test driven development must include load and scalability
testing using realistic network bandwidth and full client user
interface testing.

6

On Sun, 23 Sep 2007 19:16:26 -0000, forrie wrote:

I presume most people here read today’s article on Slashdot which had
some critique about Ruby and scaling to a large architecture.

I didn’t see any critiques about scaling Rails to a large
architecture…
it was an article by Derek of CDBaby, saying how he finally gave up
trying
to port his existing PHP application to Rails, and went back to PHP.

Nothing about scaling at all - just that (a) Rails can’t do anything PHP
can’t do (which is true for any two languages, really), and (b) he had
to
reinvent large parts of Rails to get it to do what he wanted, and (c)
migrating an existing application to a new framework is a pain, and
doubly
so with Rails which likes to make a lot of assumptions about how data is
laid out. All true.

Back to scaling:

The honest truth is that very few Rails sites have grown to the point
where
they have to worry about scaling in an enterprise-y sense. Some of the
larger sites have dealt with multiple front-end web servers. Some of
the
very large sites have dealt with read-only database replication to
multiple
back-end servers. Twittr, probably the largest, has faced their own
unique
issues. But there aren’t a lot of AOL/Google/eBay/Amazons in the Rails
world.

Part of it is that Rails sites tend to be database-y, not message-y.
There’s not a lot of shared state and concurrency, which is always the
fun
part of scaling. Part of it is that Rails is (a) relatively new and (b)
not good for porting existing sites; therefore, very little written in
Rails has had the time to go from zero to Amazon.

The 1.8 ruby interpreter, as znmeb said, is fairly slow. JRuby is
catching
up to it, and in some cases exceeding it, and you can run JRuby-on-Rails
today. And over the next year, there will be even more options.

Only you can know if the interpreter speed of the front-end web server
is
going to be a bottleneck in your site.

Here are some helpful Google terms to research Rails scaling:

evented mongrel
nginx
pound
twittr
joyeur
engineyard
multiple-databases

–
Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

7

Is there a good place to go to learn more about designing scalable apps
in general and rails apps in particular?

8

On Sep 23, 9:04 pm, Dave S. [email protected]
wrote:

Is there a good place to go to learn more about designing scalable apps
in general and rails apps in particular?

Well … I would start with this book:

Performance Solutions: A Practical Guide to Creating Responsive,
Scalable Software, Dr. Connie U. Smith and Dr. Lloyd G. Williams

9

Dave S. wrote:

Is there a good place to go to learn more about designing scalable apps
in general and rails apps in particular?

Joyent’s slides by Jason Hoffman on “Scaling Rails Applications from the
Bottom Up” provide a nice peek into the matter too.

As for the Slashdot article: I’ve read it with interest, but have found
it to be mostly lacking in detail. There’s definite proof out there that
Rails has excellent scalability properties due to its statelessness,
process-based orientation and distributed session stores.

That he found that rewriting an application into another language gives
diminishing returns is of course nothing new. That “cold turkey”
approach seldom has good payback rates. For one thing, the investment
into building the same thing over again is a steep one. Then secondly,
the maturity of the rewritten application is by definition lower than
that of the existing application that has stood the test of time and got
most bugs ironed out.

Again, I think it’s good to not lose ourselves in our Rails evangelism
and actively play the devil’s advocate, but that particular posting
didn’t particularly sway me.

–
Roderick van Domburg
http://www.nedforce.com