4 ms·

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

wgjordan 9y ago
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.
- swsieber 9y ago
  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...
- rlander 9y ago
  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.

wgjordan 9y ago

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.

swsieber 9y ago
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...
rlander 9y ago
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.