3 ms·

I'd throw this hat into the arena, which is the creator of Phoenix trying to push the framework to its limits (from a few years ago) and getting 2MM active webs

by ghayes 7y ago

I'd throw this hat into the arena, which is the creator of Phoenix trying to push the framework to its limits (from a few years ago) and getting 2MM active websocket connections from one server: https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-...

leeoniya 7y ago
or 1MM on an old laptop with uWebSockets.js: https://medium.com/@alexhultman/millions-of-active-websockets-with-node-js-7dc575746a01 https://medium.com/@alexhultman/millions-of-active-websocket...
taspeotis 7y ago
I think that's a good example of how Phoenix can scale but not necessarily how fast it is. Scale is one part of performance but I should have made it more clear: I'm interested in how fast it can be. Looking at those charts it takes them 7.5 minutes to reach 2 million subscribers. Without knowing how much work is involved for each subscription it's hard to take away information about its speed.
- dnautics 7y ago
  Why do you care so much about pure speed out of context?
- kilburn 7y ago
  > I should have made it more clear: I'm interested in how fast it can be. The answer you are looking for is: much slower than .NET core. The "being good at multiprocessing" of the BEAM VM people are bringing up is not about raw speed at it: it is about giving you the tools to actually being able to do multiprocessing in a sensible, stable manner. For instance, what happens if a bug in your program blocks threads for a long time in .NET core? What if one thread crashes? Do you have any guarantees that one thread cannot affect others in any way? Etc. Some developers think that giving up raw performance for guarantees in these areas makes sense. Other developers think they can deal with those issues without nice guarantees from the platform and thus prefer the speed. There's no definitely right answer...
  - nathan_long 7y ago
    Another consideration: Phoenix PubSub makes it simple and performant to add more servers. So if one (say) chat app server can provide acceptable performance for N users, you can serve N more users by adding another node. See the architecture of Phoenix Channels (which powers LiveView and other websocket-based solutions in Phoenix): https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html

by ghayes 7y ago

leeoniya 7y ago

or 1MM on an old laptop with uWebSockets.js: https://medium.com/@alexhultman/millions-of-active-websockets-with-node-js-7dc575746a01 https://medium.com/@alexhultman/millions-of-active-websocket...

taspeotis 7y ago

I think that's a good example of how Phoenix can scale but not necessarily how fast it is. Scale is one part of performance but I should have made it more clear: I'm interested in how fast it can be. Looking at those charts it takes them 7.5 minutes to reach 2 million subscribers. Without knowing how much work is involved for each subscription it's hard to take away information about its speed.

dnautics 7y ago
Why do you care so much about pure speed out of context?
kilburn 7y ago
> I should have made it more clear: I'm interested in how fast it can be. The answer you are looking for is: much slower than .NET core. The "being good at multiprocessing" of the BEAM VM people are bringing up is not about raw speed at it: it is about giving you the tools to actually being able to do multiprocessing in a sensible, stable manner. For instance, what happens if a bug in your program blocks threads for a long time in .NET core? What if one thread crashes? Do you have any guarantees that one thread cannot affect others in any way? Etc. Some developers think that giving up raw performance for guarantees in these areas makes sense. Other developers think they can deal with those issues without nice guarantees from the platform and thus prefer the speed. There's no definitely right answer...
- nathan_long 7y ago
  Another consideration: Phoenix PubSub makes it simple and performant to add more servers. So if one (say) chat app server can provide acceptable performance for N users, you can serve N more users by adding another node. See the architecture of Phoenix Channels (which powers LiveView and other websocket-based solutions in Phoenix): https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html