Multithreaded Rails is better than Async Rails, and Rainbows is cooler than Node | Hacker News Reader

Multithreaded Rails is better than Async Rails, and Rainbows is cooler than Node

unlimitednovelty.com

63 pointsbascule16 comments

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.

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.

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.

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.

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?

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

you can use ree and passenger instead of mongrel to save a lot of ram.

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

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.

Exactly. We are in fact running 10 mongrels.

4 gigs for a search index is rather meaningless. It's based on the size and number of documents you need to index, and not so much on your language or tool of choice.

Correct. But the lucene index requirement was bounded by the fixed size of a CMS. There were ~5k products and they were aggregating consumer reviews from various sites. The 4GB was not an strict limit, but it was what we needed to store all the user reviews of all the products, allowing for up to 20 reviews per product.

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.

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.

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?

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

Reply on news.ycombinator.com