

Multithreaded Rails is better than Async Rails, and Rainbows is cooler than Node - bascule
http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is-generally-better.html

======
dylanz
This is a fantastic post, and I definitely jive with his opinions.

Note that the title to the post is quite misleading, and it's more about the
general state of affairs in regard to the async / process / thread debate.

I was @ OSCON and watched Ilya's presentation. It was very well done, but one
of his slides was a bit too objective to Unicorn. Eric has done a fantastic
job on the software, and there "are" reasons to use it (Rainbows! as well).

Like Zed & Jacquem's discussions on poll vs epoll, I think Zed did a great job
@ stating the obvious... use the right tool for the right job. The same
applies here.

------
kqueue
Threads are bad for highly concurrent systems that wants to run fast. Running
10000 threads will result in huge amounts of context-switching because it is
the kernel's job to schedule the threads and run them.

Now compare that to coroutines, where you can switch between 10000 threads in
the userland.

If you want to take advantage of cores when using coroutine, then run several
coroutine schedulers, each in a pthread, and let them communicate over local
sockets.

~~~
bad_user
With coroutines multithreading is "cooperative". It's your job to release
control to the run-loop.

Doing it efficiently is an art and the OS is a lot more efficient than you,
even with all the context switching. Going async is premature-optimization in
my opinion, especially since with a Java server you can get to a couple
thousands of synchronous requests/second easily.

You also missed the point of the fucking article.

~~~
kqueue
Hmm, obviously you haven't written any serious http proxy/server that required
to handle 10k+ of concurrent connections. Couple of thousands of sync
connections is nothing in high performance servers.

There isn't much scheduling about coroutines, you wake up the coroutine on the
event that it slept on (read/write/sleep), that's it. If you want to
prioritize, you can do so, but with minimal advantage.

>Doing it efficiently is an art and the OS is a lot more efficient than you,
even with all the context switching

At this point, I am pretty sure you don't understand context-switching and its
implications, and you don't know how coroutines work.

------
therockhead
It been a while since i played with Rails so was surprised to hear that Rails
is now multithreaded. Has any one here deployed Rails in this configuration
and is it stable?

~~~
dasil003
I love the idea of this since it would save a _shitload_ of RAM on our app
which has mongrels pushing 500MB. But realistically it scares me because in
Ruby you can do so many things that aren't threadsafe. Rails being threadsafe
is all fine and dandy, but unless you know what you're doing and audit your
code thoroughly, it's probably pretty risky for an existing application (to
say nothing of various gems).

~~~
mahmud
I had a client that had a Java app that required 4GB as minimum. And another
4GBs for the in-memory Lucene index.

~~~
k7d
The point is that Java webapps are multihreaded. Classic Ruby apps require
dedicated process for every parallel request. Hence your 4GB java app may
still be more efficient than 500MB Mongrels.

~~~
dasil003
Exactly. We are in fact running 10 mongrels.

------
js4all
Great article. I agree with the easier programming model in the threaded world
vs. event callbacks.

I miss a benchmarked backing of the performance claims. All I have seen in
benchmarks is, that evented IO is performing better in real life, partly due
to better memory usage.

This point is missing in this article. Threaded models have an inherently
higher memory usage compared to evented models.

~~~
bad_user
It's not the memory-usage that bites you when using pthreads.

It's the N:M problem ... how to map N threads on M cores. The OS kernel does
time-slicing if N > M, and this bites you because context-switching between
threads is costly, and the more threads you have, the more context-switching
the kernel needs to make.

On the other hand, with a server on top of the JVM you can get to a couple of
thousands reqs/second without async I/O. The app I'm working on right now
reaches ~ 2000 reqs/second.

Even if some web app does 500 requests / second, who needs more than that?
Google? Twitter? Most apps don't.

Of course, in the context of Rails ... performance has always been shitty, and
I can't blame people for searching silver bullets. Unfortunately people in
general lose sight of the general context ... platforms need proper pthreads
integration without a retarded GIL.

------
shoover
Why do green threads always get thrown under the bus unequivocally? Aren't
Ruby's green threads essentially coroutines that yield the processor when they
wait for IO? So for an IO-bound app, which seems to be what evented framework
users are concerned about, why can't you just write normal synchronous IO
calls and run multithreaded Rails on C Ruby and be fine?

------
binspace
> The "threads are bad" cargo cult has often lead people to pursue
> "interesting" solutions to various concurrency problems in order to avoid
> using threads.

I know. Redis and Memcached are definitely cargo cult programs. ;-)

Seriously though, I'm not sure if I follow why it's a cargo cult. Evented
programs, as the author knows, is a way to avoid I/O blocking. Sometimes it's
not the right tool for the job, however I've been pretty happy learning the
evented idioms. It helped me to more clearly think about client/server and web
service communication.

Maybe zealot would be more appropriate to cargo cult member?

