Rails - Sep 2007 - Scaling Ruby on Rails (and related Slashdot article today)

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!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 23, 12:16 pm, forrie
<for...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
>
> 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!
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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 23, 1:16 pm, znmeb <zzn...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Sep 23, 12:16 pm, forrie
<for...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.

http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

But I didn''t see anything about scaling.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On 9/23/07, Jay Levitt <jay+news-WxwZQdyI2t0@public.gmane.org>
wrote:
>
>
> 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 Levitt                |
> 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 23, 2:46 pm, "Marc Byrd"
<dr.marc.b...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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. :)

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

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



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Is there a good place to go to learn more about designing scalable apps 
in general and rails apps in particular?
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 23, 9:04 pm, Dave Smith
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Dave Smith 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
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---