Ruby Scales just fine!

ruby-talk
21

Alex Young wrote:

James Edward Gray II wrote:

Hi,

>Soo........ Ruby DOES use multiple cores? I read somewhere that it
>didn't (probably this thread).

Single Ruby process does not. But we can use as much cores we have by
forking processes, and usually it's the case for web applications.

So fork() moves to a new processor if there is one, else a new thread?

fork() creates another process which your schedular is free to handle
as it sees best. This may mean running that process on a different
CPU, if the schedular decides that's the way to go.

OT, but is there a combination of libraries/OS/network-level
accoutrements that would allow a scheduler to migrate the process to
another host on fork()?

If you mean the "native" scheduler that's built in to the OS, you or
someone would have to write a library extension in C to make that
happen, which is OS dependent, and in the case of Linux, kernel version
dependent as well.

In general, however, unless you *really* *really* know what you're doing
and *why* you're doing it, you're better off letting the OS scheduler do
its things without even trying to give it *hints* on how to treat your
code. It's not nice to fool the scheduler -- that way lies deadlocks,
race conditions, starving philosophers, etc.

Just throw hardware at it -- lots of cores, lots of RAM, lots of
light-weight processes communicating by message passage and immutable
objects a la Erlang. The next version of Event Machine will have the
underlying mechanisms to make this work.

···

On Sep 25, 2007, at 8:24 PM, Ari Brown wrote:

On Sep 25, 2007, at 8:38 PM, Yukihiro Matsumoto wrote:

In message "Re: Ruby Scales just fine !" >>>> on Wed, 26 Sep 2007 09:28:36 +0900, Ari Brown <ari@aribrown.com> >>>> writes:

22

http://www.mosix.org/
http://openmosix.sourceforge.net/

"The latest version of MOSIX, called MOSIX2, is compatible
with Linux-2.6. MOSIX2 is implemented as an OS virtuallization
layer that provides to users and applications an SSI with
the Linux run-time environment. It allows applications to
run in remote nodes as if they run locally. Users run their
regular (sequential and parallel) applications while MOSIX
transparently and automatically seek resources and migrate
processes among nodes to improve the overall performance."

···

On 9/26/07, Alex Young <alex@blackkettle.org> wrote:

James Edward Gray II wrote:
> On Sep 25, 2007, at 8:24 PM, Ari Brown wrote:
> fork() creates another process which your schedular is free to handle as
> it sees best. This may mean running that process on a different CPU, if
> the schedular decides that's the way to go.

OT, but is there a combination of libraries/OS/network-level
accoutrements that would allow a scheduler to migrate the process to
another host on fork()?

23

Here's a recent presentation from RailsConf Europe (actually Jason has
given a similar talk several places) which puts the leverage of the
language/application framework in perspective for web apps.

http://jxh.bingodisk.com/bingo/public/presentations/JHoffmanRailsConf-Berlin-Sept2007.pdf

Anyone who thinks that it's essential for Ruby to have better thread
support to survive, and has an open mind MIGHT think differently after
reading this.

···

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

24

That is a truly great presentation.

The *only* thing I might quibble with is the "one vendor" suggestion. If
you're really going to be that big, you don't really want to tie your fate
to one vendor:

* If you're small potatoes, you're not important to them
* If you're the big cheese, you can overwhelm their capacity
* Either way, you have no leverage if they have no competition
* You'll get more data on relative failure rates, performance, bugs, etc.

One *configuration*, yes, but one vendor leads to heartache.

As AOL was scaling in the 1990s, we nearly always had two major vendors for
any one component, plus at least one experimental vendor. We discovered
very quickly which big-iron kernels had better TCP stack performance, which
hard drive brands failed more often, etc. And we got great prices, because
we could always to go The Other Guy.

In the end, the biggest "single vendor" we were tied to was the RBOCs,
which couldn't build local exchanges fast enough to provide enough dial
tones to local customers, since we were seriously messing with their
simultaneous-user projections, all of which assumed voice rather than data.
Probably not an issue anymore.

···

On Thu, 27 Sep 2007 02:40:06 +0900, Rick DeNatale wrote:

Here's a recent presentation from RailsConf Europe (actually Jason has
given a similar talk several places) which puts the leverage of the
language/application framework in perspective for web apps.

http://jxh.bingodisk.com/bingo/public/presentations/JHoffmanRailsConf-Berlin-Sept2007.pdf

Anyone who thinks that it's essential for Ruby to have better thread
support to survive, and has an open mind MIGHT think differently after
reading this.

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