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.
From what I have learned in the past (and that may not be very
complete yet!), Java scales very well due to it's VM. I think Java is
considered a static-typed language versus dynamically-typed language
(a la Ruby), whatever differences that means at that level.
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.
I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
probably not the most optimal method - considering their load
balancing was based on connections not actual system load, etc.
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.
From what I have learned in the past (and that may not be very
complete yet!), Java scales very well due to it's VM. I think Java is
considered a static-typed language versus dynamically-typed language
(a la Ruby), whatever differences that means at that level.
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.
I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
probably not the most optimal method - considering their load
balancing was based on connections not actual system load, etc.
Thanks!
Hmmm...Are you talking about the Derek Silvers CD Baby blog post? Derek was talking about Ruby on Rails, not Ruby, and none of his 7 reasons had to do with the scalability of RoR.
Or have I missed another Ruby post on Slashdot today?
In any case, this is a Ruby-specific list. There's tons of people on the Ruby On Rails mailing list that would love to debate this issue with you. See http://www.rubyonrails.com/community\.
I presume most people here read today's article on Slashdot which had
some critique about Ruby and scaling to a large architecture.
Nope.
I go with Dave Thomas's verbiage "Ruby stays out of your way". That says it all - dynamic typing, clear simple statements, endless extensibility, and realistic scaling, all in a nutshell.
I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
That's not scaling! (Okaaay, that's only one aspect of scaling!)
How did your Java design itself scale? The rate you add new features - did it go up or down over time? _That's_ scaling. If the rate doesn't slow down, you have time to tune your code to speed it up and handle more users...
Hmmm...Are you talking about the Derek Silvers CD Baby blog post? Derek
was talking about Ruby on Rails, not Ruby, and none of his 7 reasons had
to do with the scalability of RoR.
Or have I missed another Ruby post on Slashdot today?
In any case, this is a Ruby-specific list. There's tons of people on the
Ruby On Rails mailing list that would love to debate this issue with
you. See http://www.rubyonrails.com/community\.
I recently rejoined the Rails list, mostly because I'm looking for a
Rails application to include in my benchmark suite. "forrie" posted a
similar question on the Rails list and I answered it there.
But ... you're right -- the article on Slashdot is just a pointer to the
O'Reilly Ruby blog entry about the CD Baby migration from PHP to Rails
and back to PHP, with very little about scalability.
So ... while I've got your attention, I'm *still* looking for an open
source Rails application to add to my benchmark suite. So far, what's on
the Rails site in that category is rather out of date, but I think there
are one or two there I can use (rTPlan and Substruct). What I need is an
open source Rails application *with complete installation and
configuration instructions* -- that is, don't assume I wrote the thing
and know how to set up the databases, etc.
That's actually quite good. Thanks for the URL -- I enjoyed the read.
I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).
Hell, two years should be enough time to get something working in COBOL,
let alone Rails.
···
On Tue, Sep 25, 2007 at 01:04:21PM +0900, Phlip wrote:
>I presume most people here read today's article on Slashdot
Geez - I wish I could trash-talk Rails like that. I need a way to get my
blog entries to the top of the commented-on lists!
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."
I presume most people here read today's article on Slashdot which had
some critique about Ruby and scaling to a large architecture.
Nope.
Same here.
I go with Dave Thomas's verbiage "Ruby stays out of your way". That says it all - dynamic typing, clear simple statements, endless extensibility, and realistic scaling, all in a nutshell.
I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
That's not scaling! (Okaaay, that's only one aspect of scaling!)
It definitively is. One aspect of Ruby that hinders scaling is the absence of native threads IMHO. On the other hand, mechanisms are provided for IPC (DRb for example) which are easy to use and thus may be counted as compensating at least partially for the lack of native threading.
How did your Java design itself scale? The rate you add new features - did it go up or down over time? _That's_ scaling. If the rate doesn't slow down, you have time to tune your code to speed it up and handle more users...
IMHO this is not scaling (well, at least not if you follow common usage) but extensibility or flexibility of the design which translates into developer efficiency. Which does not say this is superfluous or the wrong measure, not at all. I just don't think "scalability" is the wrong term here.
On 9/23/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Tim Hunter wrote:
> Hmmm...Are you talking about the Derek Silvers CD Baby blog post? Derek
> was talking about Ruby on Rails, not Ruby, and none of his 7 reasons had
> to do with the scalability of RoR.
>
> Or have I missed another Ruby post on Slashdot today?
>
> In any case, this is a Ruby-specific list. There's tons of people on the
> Ruby On Rails mailing list that would love to debate this issue with
> you. See http://www.rubyonrails.com/community\.
>
I recently rejoined the Rails list, mostly because I'm looking for a
Rails application to include in my benchmark suite. "forrie" posted a
similar question on the Rails list and I answered it there.
But ... you're right -- the article on Slashdot is just a pointer to the
O'Reilly Ruby blog entry about the CD Baby migration from PHP to Rails
and back to PHP, with very little about scalability.
So ... while I've got your attention, I'm *still* looking for an open
source Rails application to add to my benchmark suite. So far, what's on
the Rails site in that category is rather out of date, but I think there
are one or two there I can use (rTPlan and Substruct). What I need is an
open source Rails application *with complete installation and
configuration instructions* -- that is, don't assume I wrote the thing
and know how to set up the databases, etc.
Ruby scales just fine as long as you are willing to throw a ton of
compute hardware at it !
I believe Twitter is successfully using Ruby for their site but then
they have also invested in a ton of servers dedicated to running
hundreds of Mongrels.
So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !
Ruby Rocks !
···
On Sep 25, 1:15 am, Chad Perrin <per...@apotheon.com> wrote:
On Tue, Sep 25, 2007 at 01:04:21PM +0900, Phlip wrote:
> >I presume most people here read today's article on Slashdot
> Geez - I wish I could trash-talk Rails like that. I need a way to get my
> blog entries to the top of the commented-on lists!
That's actually quite good. Thanks for the URL -- I enjoyed the read.
I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).
Hell, two years should be enough time to get something working in COBOL,
let alone Rails.
--
CCD CopyWrite Chad Perrin [http://ccd.apotheon.org]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."
I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).
Hell, two years should be enough time to get something working in COBOL,
let alone Rails.
I don't think it was a matter of not getting something working -- IIRC
CD Baby did *work* when it was in Rails. In reality, I think it was that
he didn't understand MVC, Ruby or Rails when he started the migration --
it just looked cool, so he went out and hired a Rails programmer to do it.
>
>That's not scaling! (Okaaay, that's only one aspect of scaling!)
It definitively is. One aspect of Ruby that hinders scaling is the
absence of native threads IMHO. On the other hand, mechanisms are
provided for IPC (DRb for example) which are easy to use and thus may be
counted as compensating at least partially for the lack of native threading.
Agreed. This is a far more useful argument against Ruby's ability to
scale than benchmarks from some website.
>How did your Java design itself scale? The rate you add new features -
>did it go up or down over time? _That's_ scaling. If the rate doesn't
>slow down, you have time to tune your code to speed it up and handle
>more users...
IMHO this is not scaling (well, at least not if you follow common usage)
but extensibility or flexibility of the design which translates into
developer efficiency. Which does not say this is superfluous or the
wrong measure, not at all. I just don't think "scalability" is the
wrong term here.
It's scalability of code, but not of system load handling. There are
different possible uses of the term "scale", and I think some of us are
running up against that discrepancy. You're talking about the
scalability of an application, and Phlip is talking about the scalability
of the development project behind the app, from what I see.
···
On Wed, Oct 03, 2007 at 06:40:02PM +0900, Robert Klemme wrote:
On 23.09.2007 21:08, Phlip wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
W. Somerset Maugham: "The ability to quote is a serviceable substitute for
wit."
I admit to being puzzled by the general fascination
with threads (native or not) for solving scaling
problems.
Good old processes have always seemed like a reasonable
way to partition problems and take advantage of
concurrency opportunities due to waiting on I/O
(single processor) or the parallel nature of a
CPU-bound calculation (multi-processor).
Processes also prevent the kind of problems associated
with concurrent access to shared memory that are
inherent in a multi-thread/single-process model.
A multi-process solution can more easily be
retargeted to a multi-machine solution across a network
than can a multi-thread solution.
I suspect that language and OS features have a great
affect on the concurrency model a programmer might
select or prefer.
I'm not suggesting that processes are in all cases
preferred to threads just that I would tend to explore
a multi-process solution *first* before a multi-thread
solution.
···
On Oct 3, 2007, at 5:40 AM, Robert Klemme wrote:
It definitively is. One aspect of Ruby that hinders scaling is the absence of native threads IMHO. On the other hand, mechanisms are provided for IPC (DRb for example) which are easy to use and thus may be counted as compensating at least partially for the lack of native threading.
Depends what you mean by "scaling". When I think of scaling, I think of
tens or hundreds of thousands of servers running
AOL/eBay/Amazon/Google-style apps. At that level, threads don't matter
much; what matters is that your app scales near-linearly with hardware
(what we used to call "dollar scalable").
What do you mean by scaling?
···
On Wed, 03 Oct 2007 11:37:01 +0200, Robert Klemme wrote:
It definitively is. One aspect of Ruby that hinders scaling is the
absence of native threads IMHO. On the other hand, mechanisms are
provided for IPC (DRb for example) which are easy to use and thus may be
counted as compensating at least partially for the lack of native threading.
--
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
Question is, why is his site important enough to warrant him writing on anything?
It's still a crappy looking site, always has been. I could care less what he has to say for or against a language or framework. (which he can't seem to understand the difference or separation between)
He did say he was not fond of frameworks. So he sticks to PHP alone which is a mishmash of functions.
I don't think that guy is qualified to say much about building software.
2 years to rebuild in Rails?! How?!
Simple. You can't force an existing database structure onto a framework that has an ORM. Doesn't work well if at all.
You can migrate the data. easy.
···
On Sep 25, 2007, at 7:28 PM, M. Edward (Ed) Borasky wrote:
Chad Perrin wrote:
I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).
Hell, two years should be enough time to get something working in COBOL,
let alone Rails.
I don't think it was a matter of not getting something working -- IIRC
CD Baby did *work* when it was in Rails. In reality, I think it was that
he didn't understand MVC, Ruby or Rails when he started the migration --
it just looked cool, so he went out and hired a Rails programmer to do it.
Assuming about an 80k salary and a 2,000 dollar server, a server is worth
about 50 hours of programmer time.
I just figured I'd provide a simple starting place for comparing the cost
of software development with that of hardware upgrades.
···
On Tue, Sep 25, 2007 at 10:40:04PM +0900, Ruby Maniac wrote:
Ruby scales just fine as long as you are willing to throw a ton of
compute hardware at it !
I believe Twitter is successfully using Ruby for their site but then
they have also invested in a ton of servers dedicated to running
hundreds of Mongrels.
So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
awj @reddit: "The terms never and always are never always true."
I'm confused. If it worked . . . why did he throw it away and redo it in
PHP?
···
On Wed, Sep 26, 2007 at 09:28:08AM +0900, M. Edward (Ed) Borasky wrote:
Chad Perrin wrote:
> I had a forehead-smacking moment while reading that, where I realized
> that *of course* it's true that after two years of not getting anything
> substantially right, there's obviously something else wrong besides
> choosing the wrong tool (if it's wrong for that purpose at all, which
> does not appear to be a settled matter from where I'm sitting).
>
> Hell, two years should be enough time to get something working in COBOL,
> let alone Rails.
I don't think it was a matter of not getting something working -- IIRC
CD Baby did *work* when it was in Rails. In reality, I think it was that
he didn't understand MVC, Ruby or Rails when he started the migration --
it just looked cool, so he went out and hired a Rails programmer to do it.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade.
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?
I'm not suggesting that processes are in all cases
preferred to threads just that I would tend to explore
a multi-process solution *first* before a multi-thread
solution.
