5 ms·
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 pro
by easychris 9y ago
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.
- johnbellone 9y agoNot sure why you are being voted down. This is exactly how you would scale to multicore with Puma.
- rlander 9y agoBecause 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.
- easychris 9y agoThat'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.