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.
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.
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()?
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.
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.
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 Sep 25, 2007, at 8:24 PM, Ari B. 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()?
“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.”