Hacker News Reader

Comment by rlander | Hacker News Reader

No it can't. It's technically impossible for a Rails app to utilize all cpu cores because of the GIL. You're confusing two different things: the web server and the actual Ruby app. The rails app is still limited by the GIL and, therefore, runs within a single process.

View on HN

So you're saying that when the OP talks about 'app can utilize all cpu cores', he's specifically referring to individual requests spawning multiple concurrent threads and therefore utilizing all CPU cores in isolation, as opposed to the web server utilizing all CPU cores across multiple concurrent requests by serving them on separate processes/threads? I would be interested if the former was the case (and would be interested in practical examples), but I highly doubt it.

Yes, the former. He's saying that his Elixir app should scale linearly to N times faster on N cores processors (up to ~20 cores).

Rails can scale in this way too, by serving concurrent requests across multiple forked worker-processes (note that the GIL doesn't prevent multiple _processes_ from running Ruby code concurrently across multiple cores, only multiple threads in a single process).

At first, it sounded like you were implying (by distinguishing between the web server and 'the actual Ruby app') that Phoenix automatically parallelizes portions of an _individual_ request across multiple threads/cores using some special asynchronous dataflow-paradigm primitives or something. It would be unique and truly awesome if that were true, but I still highly doubt it.

I don't doubt that Phoenix probably delivers orders-of-magnitude better performance than Rails in many other respects, but 'utilizing all cpu cores without you doing anything special' is nothing unique to Phoenix over Rails as I understand it.

The entire basis of Erlang (well, it's VM, BEAM) are to be built from asynchronous primitives. From what I know, Phoenix works well with it.

So yes, Phoenix does "automatically parallelizes portions of an _individual_ request across multiple threads/cores using some special asynchronous dataflow-paradigm primitives or something."

Edit: quoting you is not meant to be condescending... I'm not sure if it comes off that way or not.

Edit 2: Not an expert and it may not be parallelized, but portions of the requess can be doled out to other threads, and when there's any down time from IO, other requests can use the thread...

Well, by its nature a web request is sequential, so in 95% of the cases it's just:

  process response -> deserialize -> put/get something from the DB -> send response

However, let's say you need to send off many requests to multiple external services in order to respond to a particular request. These would be trivially parallelized in Erlang.

Another thing to note is that, let's say Puma is running 8 workers and a bug crashes the app. Every client connected to that worker is going to lose its connection while that worker is restarted. In Erlang, you have one process for each client so only one client notices the crash.

And finally, the overhead of starting multiple Ruby processes (in this case OS processes) per Ruby interpreter is way, way larger than a starting multiple Erlang processes. It's a difference of 300MB vs 2KB.

I think that's not true. If you have e. g. 4 cores, and you start Puma with 4 workers (i. e. processes) it will utilize all cores.

I guess you're mixing up processes with Ruby threads.

You normally start as many Puma processes as your CPU/Core count with probably additional threads per workers.

Not sure why you are being voted down. This is exactly how you would scale to multicore with Puma.

Because of the GIL, Ruby threads will be run sequentially, within a single process, even thought they appear to be parallel. So, if a part of a program blocks the process, your CPU is being under-utilised.

Erlang, on the other hand, has a preemptive scheduler that is capable of keeping all cores hot.

That's true for threads (although most of your threads should be blocked by IO, e. g. DB queries, and that means the GIL lock isn't a big issue).

But the beauty of HTTP is that you can scale simply by adding more "endpoints". That means you can add as many processes (workers) as necessary to utilize all CPUs, or even add as many servers as you can afford.

I'm not saying that Elixir does not do a better job with it's lean processes and built-in OTP stuff.

But it's not true that you can't utilize all CPUs with a Rails app.

> The rails app is still limited by the GIL and, therefore, runs within a single process.

Rails app-servers fork multiple OS processes to utilize all CPU cores despite the GIL.

If you define a 'Rails app' as a single un-forked OS process (a definition I've never heard before) then yes, tautologically, a 'Rails app' could not utilize all CPU cores because of the GIL.

Reply on news.ycombinator.com