3 ms·

Should have used https://github.com/uWebSockets/uWebSockets https://github.com/uWebSockets/uWebSockets for Node.js, if performance was the objective.

abritinthebay 10y ago
There's a lot that could be improved about the Node one. The library and the the lack of clustering (so you can compare apples to apples) are the main two. Honestly? Running at 39% of the connections on one core is pretty impressive. Especially with its low memory footprint.
- frogglet 10y ago
  I'm not a node.js dev so I might be wrong here, but I imagine clustering would complicate the broadcast, no? I was under the impression that communication between the nodes of the cluster can be a pain.
  - tracker1 10y ago
    In a way yes, you'd need a control channel to centralize the broadcast to the other processes. In more common use cases, Redis is used in conjunction with node for these types of things. There are relays for redis with sockjs, socket.io and others to make the setup/configuration a bit easier to work with.
  - abritinthebay 10y ago
    For sure, it wouldn't be as short, but it wasn't a LoC benchmark so...
- tracker1 10y ago
  There are of course other advantages to a Node implementation (first class simple objects to/from JSON being high among them). Far less of a disconnect to the front end is huge. Also, if you need to have the reliability/scale of more than one server anyway, then some of that ground can be overcome with clustering and/or multiple instances. Though clustering would have meant the need for another control channel.. that said, I'd be surprised if Redis + Node(clustered) didn't perform in with the leaders of the pack.
  - abritinthebay 10y ago
    Agreed on all points. With clustering -as that has overhead - I'd expect it to perform at least as fast as Elixir or Go. Of course you can also just use multiple cheaper single core servers too! I've seen that used a lot for certain applications - kinda overkill here tho.

abritinthebay 10y ago

There's a lot that could be improved about the Node one. The library and the the lack of clustering (so you can compare apples to apples) are the main two. Honestly? Running at 39% of the connections on one core is pretty impressive. Especially with its low memory footprint.

frogglet 10y ago
I'm not a node.js dev so I might be wrong here, but I imagine clustering would complicate the broadcast, no? I was under the impression that communication between the nodes of the cluster can be a pain.
- tracker1 10y ago
  In a way yes, you'd need a control channel to centralize the broadcast to the other processes. In more common use cases, Redis is used in conjunction with node for these types of things. There are relays for redis with sockjs, socket.io and others to make the setup/configuration a bit easier to work with.
- abritinthebay 10y ago
  For sure, it wouldn't be as short, but it wasn't a LoC benchmark so...
tracker1 10y ago
There are of course other advantages to a Node implementation (first class simple objects to/from JSON being high among them). Far less of a disconnect to the front end is huge. Also, if you need to have the reliability/scale of more than one server anyway, then some of that ground can be overcome with clustering and/or multiple instances. Though clustering would have meant the need for another control channel.. that said, I'd be surprised if Redis + Node(clustered) didn't perform in with the leaders of the pack.
- abritinthebay 10y ago
  Agreed on all points. With clustering -as that has overhead - I'd expect it to perform at least as fast as Elixir or Go. Of course you can also just use multiple cheaper single core servers too! I've seen that used a lot for certain applications - kinda overkill here tho.