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
it was an article by Derek of CDBaby, saying how he finally gave up
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
reinvent large parts of Rails to get it to do what he wanted, and ©
migrating an existing application to a new framework is a pain, and
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
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
very large sites have dealt with read-only database replication to
back-end servers. Twittr, probably the largest, has faced their own
issues. But there aren’t a lot of AOL/Google/eBay/Amazons in the Rails
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
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
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
going to be a bottleneck in your site.
Here are some helpful Google terms to research Rails scaling:
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