Well to detail…

• Phoenix is a library of plugs and other helpers on the Plug library, it adds no overhead over Plugs.
• Plug is a library on Elixir for simple and fast web hosting, it adds a microscopic amount of overhead over the web server (cowboy), but buys a lot in safety.
• Cowboy is an Erlang web server library designed to handle any and all kinds of network communication as-fast-as-possible, a bit ugly of an interface because of that but it is fantastic in speed, Plug on top of it makes it blissful to use for most web protocols.
• Elixir is the language that compiles to the BEAM/EVM (Erlang Virtual Machine).
• Asp.Net (the modern version, the older ones were utterly horrible) is a lot better now, but it breaks often (I know, we use it at work on some things that we cannot replace because Federal Laws…).
• .NET Core is basically mono and .NET merged, a making from when MS bought Xamarin(sp?), a normal Java-horrible-like GC’d VM, but decently fast.

Now, comparing parts to parts:

.NET Core vs BEAM/EVM:

• .NET Core will be faster on raw JIT performance, like processing numbers, but how often are you doing multi-dimensional matrix transforms in web hosting.
• BEAM/EVM barely has any JIT happening at all, but it is still very performant, however the language design combined with internal very low level async I/O allows the BEAM/EVM to outperform ‘almost’ anything on I/O (like networking, say, for webhosting) while being safer than any just about any language at all.
• However, .NET Core has very little ability to debug production, you mostly have to rely on your logs or hook up a debugger that often stops-the-world.
• Compared to the BEAM/EVM that has introspection that would make any network or server admin just drool, but it is done in a different way than you would do it on .NET Core (mostly because debugging individual instruction is as you would on .NET is hell for a concurrently real-time system).

If you need some really heavy processing, .NET is good, not great, I’d pick, say, Rust or C++ or OCaml or a host of other languages over ever touching .NET, but it is not bad. However a bad crash in it brings everything down, unlike on the BEAM/EVM where it is much safer in that it is expecting things to crash, and more importantly to handle it (not just talking about exceptions, also talking about, say, hardware failing). And if you need speed for something it is so trivial to plug in Rust or C++ or OCaml or even .NET to the BEAM/EVM via a Port (or for now kind of speed you can use any language that implements a C interface like C++ or Rust or OCaml to the BEAM/EVM as a NIF, but that incurs a hit on safety so be careful, Ports are almost always better).

Using Phoenix/Plug/Cowboy together, as they are always used together if using Phoenix, vs ASP.net they have significantly different styles of ‘work’, ASP.net’s is significantly more mutating, it can be hard to reason why something is changing where (as we’ve experienced innumerable times here at work), where in Phoenix the whole straight pipeline of Plugs is wonderfully immutable and you know where everything comes, no magic database access in views, no wondering why something is suddenly accessing the DB 20 times, no magic variables littered all over the place just to ‘tag’ crap, it just-makes-sense.

Basically for web hosting, the horizontal and vertical scaleability, for network usage, it is hard to beat Phoenix overall. Something may beat it in micro-tests like raw number performance or spamming out “hello world” to a port, but it is already close on all of those and with as close as it gets to them all with all the safety it has and scaling it has it is overall, in my opinion, unmatched, as well as it is trivial to interface it with other languages to do their specialty heavy-lifting, the BEAM/EVM makes a fantastic and safe ‘glue’ interface to other languages, even if the other languages did all the heavy work having them talk through the BEAM/EVM still gains you so much for server tasks.

During the 2M Phoenix test @josevalim sent a copy of Wikipedia article to the channel and it was delivered (please correct me if I’m wrong) in near 2 seconds to all connected clients.

There are several talks by @chrismccord on youtube about it.

My relationship with ASP.NET ended with CS course in university, so I can’t compare.

I think it tightly depends on problem we are solving, there is no silver bullet, we can just pick a more suitable tradeoffs.

Websockets and http are little bit different. Also it should be compared on same hardware. Here is a good article about measuring.

To be more apple to apple, I suggest you to build a prototype using both technologies, if you have time for this. Or pay for it if you are the boss Then ask for review from experts from both sides.

In the end you should be able to answer the following questions:

1. How do I scale horizontally and vertically?
2. Am I productive?
3. What technology features I utilize (even not consciously)?
4. How do I debug in production environment?
5. What community do I like?

I’m not addressing your question directly because performance may vary for different problems.

The second reason is because people (including myself) think they can measure all in one dimension.
If only speed matters why don’t we write in Assembly language then?

I honestly would have no clue, auto-scaling servers kind of scare me to be honest, every time I’ve calculated my usage on them (which tends to be high), I *always* find it *substantially* cheaper to just rent a server straight (I particularly like OVH, I think I can give a reference number or something if you want it?)

Phoenix/Elixir/BEAM distributes horizontally, so you can have servers all over the world chattering over a connection between them as necessary, this is actually really really easy to do if you have the hardware there.

Well I don’t use auto-scaling, but even renting a VM instead of a hardware server at OVH starts at like $3/month for decent specs (and not overloaded like dreamhost and such gets), but they tend to only be in the USA and Canada I think (honestly I’ve not looked to if they do elsewhere, they might), but there are plenty of places to choose from. I actually have one BIG hard server with OVH in Canada and a few mini-VM’s in a few locations in the USA that communicate back to the big one, it works really well for me. ^.^

A better example to use might be Eve Online as a massive singular game world. ^.^
Twitch style streaming is a slice of hell because of video encoding, I’d give that task to Youtube to be honest, not do it myself unless absolutely necessary. >.>

However yes, phoenix could do it, just segment your game world properly (lots of libraries can help with that), have in-game near parts nearby physically too and communicating, and slave out any computationally expensive math to a NIF (I’d choose Rust for this purpose) or large data processing over a Port (I’d probably use C++, Rust, or OCaml, depending on exactly what is being done). You would then have a system that could scale as well as your hardware allows while absolutely saturating the heck out of the individual pieces of hardware too, it would scale well, that is what the BEAM does.