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