Recent Criticism about Ruby (Scalability, etc.)

ruby-talk
21

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

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

There's entirely too much focus on threads these days. In many cases,
separate processes are superior to multithreading concurrency. On the
other hand, there are cases where multithreading concurrency is superior
to multiprocessing concurrency.

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.

On the other hand, sometimes it's nice to keep process overhead down.
Most of the time, however, I think multithreaded concurrency is a case of
premature optimization.

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.

Same here. That's one of the reasons that, though I know a fair bit
about multithreaded concurrency in theory, I've done very little with
multithreaded development in practice. In fact, all I've found need to
do with mutilthreaded dev so far is dealing with others' code, where the
code was implemented using multithreaded concurrency before I ever laid
eyes on it.

···

On Thu, Oct 04, 2007 at 03:06:03AM +0900, Gary Wright wrote:

On Oct 3, 2007, at 5:40 AM, Robert Klemme wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of others
we should be glad of an Opportunity to serve others by any Invention of
ours, and this we should do freely and generously."

22

Ayup. At AOL, when we grew beyond the abilities of sendmail to handle
incoming mail from the Internet, we rolled our own SMTP server. It had the
following characteristics:

- Non-threaded, event-driven main loop
- Asynchronous DNS calls
- Asynchronous database calls
- No disk I/O other than logging (which itself might have been async, I
forget)
- Therefore, no process ever waited on anything

The best configuration? One process per CPU.

···

On Thu, 4 Oct 2007 03:06:03 +0900, Gary Wright wrote:

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

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

23

To me "scaling" just means "adjusting to higher load". What you have
in mind seems a concrete solution to provide scaling but that's just
one (albeit a very common one).

Kind regards

robert

···

2007/10/3, Jay Levitt <jay+news@jay.fm>:

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.

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?

24

Ruby is infintely scalable as long as you got the bucks to pay for all
that hardware ! (*Just forget the fact that another language might
have saved some money in compute gear. I mean, don't even think about
this at-all. Why are you still reading this sentence? I told you to
forget about what those 58 server cost... Money is irrelevant to those
who love Ruby! *)

Ruby Rocks !

···

On Sep 25, 7:01 am, Glenn Gillen <glenn.gil...@gmail.com> wrote:

> So yeah, get out your checkbooks and write more checks for more
> servers and sure Ruby scales just fine !

> Ruby Rocks !

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon
X3210s

Job Security Rocks!

25

Meh, I respectfully suggest to stop feeding the guy. Nothing productive will
come of it.

Felix

···

-----Original Message-----
From: Glenn Gillen [mailto:glenn.gillen@gmail.com]
Sent: Tuesday, September 25, 2007 7:02 AM
To: ruby-talk ML
Subject: Re: Recent Criticism about Ruby (Scalability, etc.)

> So yeah, get out your checkbooks and write more checks for more
> servers and sure Ruby scales just fine !
>
> Ruby Rocks !

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon
X3210s

Job Security Rocks!

26

Question is, why is his site important enough to warrant him writing
on anything?

Actually, CD Baby is a godsend to a large number of small-scale
musicians. I think the "Code Monkey" guy sells all his music through
them.

A lot of the reactions here are just defensive. But there's no point
being defensive because the whole thing really isn't that important.
It's one guy who tried to do a massive rewrite and found out that
incremental rewrites are better. Mix in a bunch of language-crazy
programmers who care way too much about Language X vs. Language Y, put
them all together on Slashdot - where people with nothing to do come
to dis each other - and you've got a so-called big deal.

So, the moral(s) of the story:

1. Code Monkey like Fritos
2. Slashdot people argue about everything
3. Incremental rewrites pwn from-scratch rewrites

Yay. The end.

(Notice the absence of any lesson about PHP, Ruby, or Rails.)

···

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/

27

There is a lot of things that can go wrong when you do a rewrite, especially when you do a rewrite in a new language and framework.

In this particular case, from what I understand was the main problem was basically that he had a working platform in PHP, and he wanted to improve that. His experience from building the system in PHP would help immensely if he would rewrite it in... PHP. With Rails, I suspect his PHP experience would work against him, both leading him towards solutions more suitable for PHP than Rails, and also effectively steering him away from the easiest Rails-like solutions.

In addition he had problems getting the other systems - already tuned for use with his old PHP code - to play with Rails. Again this is only natural if you have built a significantly large system already.

These two factors alone can explain why building the system in Rails took so long.

So I think there's no need to be so judgemental here. I didn't feel it was a criticism against Ruby, just a warning that even the best regarded framework isn't a guarantee for success, and you should go into everything with your eyes wide open.

So no need to be rude to him.

/Christoffer

···

On 26 Sep 2007, at 05:36, John Joyce wrote:

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.

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.

28

Oops. I should have read the responses before I posted my own cost
comparison.

···

On Tue, Sep 25, 2007 at 11:01:43PM +0900, Glenn Gillen wrote:

>So yeah, get out your checkbooks and write more checks for more
>servers and sure Ruby scales just fine !
>
>Ruby Rocks !

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon
X3210s

Job Security Rocks!

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
quota by 100K; and 3) RUNS ED!!!!!!"

29

Because he was able to do it himself, and then both _read_ the code and _rewrite_ it.
Please read http://www.zedshaw.com/essays/c2i2_hypothesis.html, Gadfly Festival section,
and all on the Big Rewrite by Chad Fowler. In this case PHP was a (roughly and not at all harshly pat) alternative
for an Excel spreasdheet with VBA macros - the issue of ownership I guess. Nothing critical.

···

On Sep 27, 2007, at 12:43 AM, Chad Perrin wrote:

I'm confused. If it worked . . . why did he throw it away and redo it in
PHP?

30

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.

I think this statement with this level of generality is wrong. It depends on the schema how well it fits a particular ORM tool.

You can migrate the data. easy.

That also depends on the schemas involved. The complexity of translating a data or object model into another is mainly governed by the similarity of the schemas.

Kind regards

  robert

···

On 26.09.2007 05:36, John Joyce wrote:

31

Chad Perrin 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 !

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.

I find this perspective puzzling. In most large datacenters, the big cost of operation is neither the cost of the servers nor the cost of the development time to put code on them, it's the peripheral electricity, administration and cooling costs once the application written must be deployed to thousands of users.

An application that scales poorly will require more hardware. Hardware is cheap, but power and administrative resources are not. If you need 10 servers to run a poorly-scaling language/platform versus some smaller number of servers to run other "faster/more scalable" languages/platforms, you're paying a continuously higher cost to keep those servers running. Better scaling means fewer servers and lower continuous costs.

Even the most inexpensive and quickly-developed application's savings will be completely overshadowed if deployment to a large datacenter results in unreasonably high month-on-month expenses.

- Charlie

···

On Tue, Sep 25, 2007 at 10:40:04PM +0900, Ruby Maniac wrote:

32

Daniel DeLorme wrote:

+1
threads are a misfeature

Threads are worse than GOTO.

Yes, sometimes you need GOTO. (Locally catch-throw). Do your darndest to
avoid it!

···

--
Phlip

33

Sure; it also depends on what you mean by "higher load". Threads help with
what they now call "vertical scaling" - bigger and bigger boxes. Or,
rather, they *can* help, if you're I/O bound. (So can adding processes,
but presumably threads have less overhead.)

If you're CPU bound, splitting your operation into threads doesn't help any
more than just running more processes.

And, of course, bigger boxes are much more expensive than small boxes. We
had some apps that used to run on 8-way or 16-way machines (ten years ago
when such a things was a rarity), but we spent a lot of development effort
rearchitecting them to run on more standard hardware, because that'd be
cheaper.

···

On Thu, 4 Oct 2007 17:08:49 +0900, Robert Klemme wrote:

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?

To me "scaling" just means "adjusting to higher load". What you have
in mind seems a concrete solution to provide scaling but that's just
one (albeit a very common one).

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

34

Ruby Maniac wrote:

So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !
Ruby Rocks !

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon X3210s

Job Security Rocks!

Ruby is infintely scalable as long as you got the bucks to pay for all
that hardware ! (*Just forget the fact that another language might
have saved some money in compute gear. I mean, don't even think about
this at-all. Why are you still reading this sentence? I told you to
forget about what those 58 server cost... Money is irrelevant to those
who love Ruby! *)

Ruby Rocks !

The 58 servers next year will cost half as much. The developer next year will cost the same or more.

I work in embedded systems. The hardware / software cost analysis turns out different here. An embedded system will typically be deployed on thousands and sometimes millions of devices. Here it is worth saving pennies on compute hardware by spending big $$$ on software development and trying to keep the code as small and optimized as possible. You will still find many cheap 8bit and 16bit computers running your cars, phones and refrigerators. The cost of finding developers who can deal properly with those sorts of devices is not cheap.

However for a web server with a hardware deployment footprint orders of magnitude lower than an embedded systems deployment it doesn't make sense to try to save money on hardware. Where you will blow your budget is with the software developers.

With regards to Python/Ruby speed issues. I am currently watching a complex scheduling algorithm ticking by very slowly in a shell while I write this post. The algorithm should should have been written in C/C++ and not in Python/Psyco or Ruby and I am going nuts waiting for it to complete.

( BTW I didn't write it )

B

···

On Sep 25, 7:01 am, Glenn Gillen <glenn.gil...@gmail.com> wrote:

35

At first, let me point out this post from the Ruby on Rails weblog:

I saw the presentation myself and Jasons point was the following: as
Rails doesn't implement a stateful wrapper for HTTP as some other
Frameworks (like Webobjects) do, it is scalable by default. The "throw
more servers at it" works. The speed of the Framework is of no interest
in this case, but with the correct hardware and application layout,
Rails scales pretty linear. The thing is: Rails may have some small
features that support you in scaling, but most of this work is still
yours, Rails or not.
Scalability is much more an architectural thing then a language issue.
Often, fine-tuning your servers is much more worthwhile than fine-tuning
your application.

The post on Slashdot was a typical for Slashdot: harsher then necessary.
The only thing that this poor guy stated, was that he was much more
proficient in PHP than in Ruby and his environment was a
PHP-environment. As it is entirely possible to write good Software (and
Frameworks) in PHP, so I do support his reasons. But they are heavily
bound to his environment, so his reasons might not be the applicable to
yours.

Greetings
Skade

···

--
Posted via http://www.ruby-forum.com/.

36

How do you know that was the reason? The impression I got from the
lengthy, slashdotted explanation was that the project was unfinished
after two years, so he decided to junk it and start over in PHP.

···

On Thu, Sep 27, 2007 at 02:34:34PM +0900, julik wrote:

On Sep 27, 2007, at 12:43 AM, Chad Perrin wrote:

>I'm confused. If it worked . . . why did he throw it away and redo
>it in
>PHP?

Because he was able to do it himself, and then both _read_ the code
and _rewrite_ it.
Please read http://www.zedshaw.com/essays/c2i2_hypothesis.html,
Gadfly Festival section,
and all on the Big Rewrite by Chad Fowler. In this case PHP was a
(roughly and not at all harshly pat) alternative
for an Excel spreasdheet with VBA macros - the issue of ownership I
guess. Nothing critical.

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

37

2 years to rebuild in Rails?! How?!

Big companies get in this trouble when they practice "Big Requirements Up Front". If you schedule a huge number of requirements, then try to do them all at the same time, you make development extremely hard. This is how the huge multi-billion dollar software project failures happen in the news. Rails is not immune.

The correct way to replace an old project is a process pattern called "Strangler Fig". You ask the client what's one tiny feature to add to the old system - what are they waiting for - and you implement it using the new technology. You link the old system to it, and you put it online as soon as possible.

A project that succeeds early cannot fail in 2 years. (It can be cancelled, at any time, of course, but with no difference between the cost and the amount of features deployed.)

Then you ask the client what's the next feature, and you implement this, and use it as an excuse to convert a little more of the old system into the new system. And if there's no reason to completely retire the old system, you don't. You could save 1 year like that!

Someone got ambitious, and actually believed Rails's hype, and was over-confident.

···

--
  Phlip

38

Charles Oliver Nutter wrote:

Chad Perrin 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 !

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.

I find this perspective puzzling. In most large datacenters, the big cost of operation is neither the cost of the servers nor the cost of the development time to put code on them, it's the peripheral electricity, administration and cooling costs once the application written must be deployed to thousands of users.

An application that scales poorly will require more hardware. Hardware is cheap, but power and administrative resources are not. If you need 10 servers to run a poorly-scaling language/platform versus some smaller number of servers to run other "faster/more scalable" languages/platforms, you're paying a continuously higher cost to keep those servers running. Better scaling means fewer servers and lower continuous costs.

Even the most inexpensive and quickly-developed application's savings will be completely overshadowed if deployment to a large datacenter results in unreasonably high month-on-month expenses.

- Charlie

Thank you!! It's about time somebody put a dollar figure on the cost of poor scalability and highlighted the nonsense of "adding servers is cheaper than hiring programmers." They are two entirely different economic propositions.

···

On Tue, Sep 25, 2007 at 10:40:04PM +0900, Ruby Maniac wrote:

39

Chad Perrin 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 !
>
>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.

I find this perspective puzzling. In most large datacenters, the big
cost of operation is neither the cost of the servers nor the cost of the
development time to put code on them, it's the peripheral electricity,
administration and cooling costs once the application written must be
deployed to thousands of users.

For very small operations, this is true.

An application that scales poorly will require more hardware. Hardware
is cheap, but power and administrative resources are not. If you need 10
servers to run a poorly-scaling language/platform versus some smaller
number of servers to run other "faster/more scalable"
languages/platforms, you're paying a continuously higher cost to keep
those servers running. Better scaling means fewer servers and lower
continuous costs.

Actually, when people talk about something scaling well or poorly,
they're usually talking about whether it scales linearly or requires an
ever-increasing inclusion of some resource. Something that scales very
well requires the addition of one more unit of a given resource to
achieve an increase in capability that matches up pretty much exactly
with the amount of capability per unit of resource already employed.
This is usually counted starting after an initial base resource cost.
For instance, if you have minimal electricity needs for lighting, air
conditioning, and a security system, plus your network infrastructure,
and none of that will need to be upgraded within the foreseeable future,
you start counting your electricity resource usage when you start
throwing webservers into the mix (for a somewhat simplified example). If
you simply add one more webserver to increase load handling by a static
quantity of concurrent connections, you have linear (good) scaling.

On the other hand, if you have a system plagued by interdependencies and
other issues that make your scaling needs non-linear, that kind of
resource cost can get *very* expensive. Obviously, some software design
needs are part of determining the linearality of your scaling
capabilities, but such needs often involve factors like choosing a
language that makes development easier, a framework that is already
well-designed for scaling, and so on. A language that compiles to
relatively high-performance binaries, or one that is compiled to bytecode
and executed by an optimizing VM, can help -- but that doesn't magically
make your software scale linearly. That's dependent upon how the
software was designed in the first place.

Throwing more programmers at the problem certainly won't result in a
system that scales linearly either. What a larger number of programmers
on a single project often does, in fact, is ensure that scaling
characteristics across the project are less consistent. You may end up
with one particular part of the overall software serving as a scaling
bottleneck because its design characteristics are sufficiently different
from the rest that it requires either a refactor or ever-increasing
resources as scaling needs get more extreme. Oh, and there's one more
thing . . .

Even the most inexpensive and quickly-developed application's savings
will be completely overshadowed if deployment to a large datacenter
results in unreasonably high month-on-month expenses.

Even the cheapest hardware and energy requirement will quickly become
astronomically expensive if you have to throw more programmers at it.
The more difficult a system is to maintain, the faster the needed
programmer resources grow. That's the key: programming resources don't
tend to scale linearly. Hardware resources, except in very poor examples
of software design, usually do.

···

On Wed, Oct 03, 2007 at 10:19:57PM +0900, Charles Oliver Nutter wrote:

>On Tue, Sep 25, 2007 at 10:40:04PM +0900, Ruby Maniac wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of others
we should be glad of an Opportunity to serve others by any Invention of
ours, and this we should do freely and generously."

40

"Most"? If you define "large data center" as the very top echelon,
then maybe, but even then I'd like to see some data. I expect the vast
majority (all?) of readers of this ng will be involved in scenarios in
which the cost of development time far exceeds electricity or server
costs for their deployed applications.

Part of what kept me from getting involved in Ruby sooner than I did
was my erroneous view that I wanted to be using technology that would
be sufficient to run Amazon, Ebay, etc. Little did it matter that I
wasn't pursuing that type of project - analogous to the fact that
most, if not all, Hummer drivers will never encounter serious off road
or combat situations :slight_smile:

I'm all for increasing the performance and scalability of Ruby, but I
think the productivity gains still outweigh the extra runtime costs
for most projects.

···

On Oct 3, 9:19 am, Charles Oliver Nutter <charles.nut...@sun.com> wrote:

I find this perspective puzzling. In most large datacenters, the big
cost of operation is neither the cost of the servers nor the cost of the
development time to put code on them, it's the peripheral electricity,
administration and cooling costs once the application written must be
deployed to thousands of users.