Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com