4 ms·

BEAM is not fast. You're probably going to get better performance with Node.js. It is however really really low-latency. But that doesn't help with handling loa

by tormeh 5y ago

BEAM is not fast. You're probably going to get better performance with Node.js. It is however really really low-latency. But that doesn't help with handling load. Anyway, even so I'd guess bandwidth or the database is the issue.

romanbaron 5y ago
BEAM is not fast when it comes to CPU intensive workloads. "Better performance" has many dimensions, in many (most?) scenarios of web serving the bottleneck is latency to other services (i.e. Postgres) and not the processing of the web server, like you suspect in this case as well. BEAM/Erlang/Elixir's main advantage IMHO is parallelism and "cheap" concurrency that's easy to wrap one's head around. It reuses multiple cores, and processes (lightweight threads) are both cheap (smaller stack size, per-process GC) and easy to get right (due to immutability of data structures and supervision). Also you'll get less spiky latency even under high load. Node.js main advantages are the breadth of the library ecosystem, industry familiarity and its JIT compiler (if used correctly). At the cost of more setup one can also run an instance per core if they care for parallelism. So I'd suggest that with BEAM he'd get quite a good performance both in terms of developer time and in serving many (network bound) requests on a multicore machine.
exikyut 5y ago
> BEAM is not fast > It is however really really low latency I've been interested in Erlang for a while, and reading this is intriguing. Taken literally the above makes no sense :) but it also kind of... does, sort of, and I would like to understand how this works.
- tormeh 5y ago
  There's often a tradeoff between latency and throughput. Think GC algorithms or IO buffers. The Erlang project has historically chosen the far left end of this spectrum. They also haven't cared about numerical performance at all, delegating that to C code.
  - exikyut 5y ago
    Ooooh, burst response as opposed to flat-out super tight hot loops. That honestly makes a lot of sense. Thanks!

by tormeh 5y ago

romanbaron 5y ago

BEAM is not fast when it comes to CPU intensive workloads. "Better performance" has many dimensions, in many (most?) scenarios of web serving the bottleneck is latency to other services (i.e. Postgres) and not the processing of the web server, like you suspect in this case as well. BEAM/Erlang/Elixir's main advantage IMHO is parallelism and "cheap" concurrency that's easy to wrap one's head around. It reuses multiple cores, and processes (lightweight threads) are both cheap (smaller stack size, per-process GC) and easy to get right (due to immutability of data structures and supervision). Also you'll get less spiky latency even under high load. Node.js main advantages are the breadth of the library ecosystem, industry familiarity and its JIT compiler (if used correctly). At the cost of more setup one can also run an instance per core if they care for parallelism. So I'd suggest that with BEAM he'd get quite a good performance both in terms of developer time and in serving many (network bound) requests on a multicore machine.

exikyut 5y ago

> BEAM is not fast > It is however really really low latency I've been interested in Erlang for a while, and reading this is intriguing. Taken literally the above makes no sense :) but it also kind of... does, sort of, and I would like to understand how this works.

tormeh 5y ago
There's often a tradeoff between latency and throughput. Think GC algorithms or IO buffers. The Erlang project has historically chosen the far left end of this spectrum. They also haven't cared about numerical performance at all, delegating that to C code.
- exikyut 5y ago
  Ooooh, burst response as opposed to flat-out super tight hot loops. That honestly makes a lot of sense. Thanks!