4 ms·

Still love seeing such great performance from asynchronous processing. But I’m curious, is there something special about node providing this? Or can we achieve

by par 4y ago

Still love seeing such great performance from asynchronous processing. But I’m curious, is there something special about node providing this? Or can we achieve similar performance with other async web servers (python, go, swift, rust etc?)

foepys 4y ago
The library mentioned in the article is C++ code that extends Nodejs and basically bypasses all of it. Nothing is making Nodejs special here. The Readme says: > µWebSockets.js is a web server bypass for Node.js that reimplements eventing, networking, encryption, web protocols, routing and pub/sub in highly optimized C++
fastball 4y ago
Well this isn't really NodeJS, it's written in C++. The whole point of Node is that it is a wrapper around the V8 JS engine (the one used in Chrome) that allows you to run JS specifically in a non-browser environment. This project is more an extension to Node (or as it is called in the GitHub README, a "web server bypass for Node.js). You do actually see the same kinda thing happening in other ecosystems, especially Python – something runs slower than you want it to (because Python), so you re-write it in Rust/C/C++ and hook into the extension system of the lang for a seamless DX. Off the top of my head things like `asyncpg`, `orson`, `uvloop` and esp relevant in this case `websockets` are all async libs that do this. Mildly tangential but as someone who has spent a lot of time making the Python backend for my startup run as fast as possible, I would recommend avoiding Python if performance is your primary concern.
akmittal 4y ago
Definitely possible to get similar or better performance using go, swift and rust. Python is slower in most cases so i dont think it would be possible using python(unless calling C from python)
- josephg 4y ago
  Yep. I'm also not sure if the server libraries in swift are mature & well optimized enough to handle millions of active websocket connections. Maybe someone with more swift experience can chime in! Whats the state of swift on the server these days?
nivertech 4y ago
C1M is not that impressive anymore, these days one need to do C10M;) Most of the work of accepting and holding concurrent TCP sockets done by the OS, not the language runtime. One can easily tune Linux kernel to 1M concurrent sockets. The real issues: memory usage per concurrent socket (idle or active), and ability to do something useful with all these active connections, e.g. send pings every 30s, or broadcast a message to all of them. I'm not sure NodeJS/C++ based system from this post will allow sending pings every 30s to 1M websockets, let alone to do something useful with them, beside some low-traffic or infrequent notifications (Of course one always need to perform realistic loadtests in order to answer these kinds of questions). Erlang/Elixir/BEAM have a relatively large memory usage per active socket, but it allows doing something useful with them under an easy to use programming model (read: no callback hell).
- nkristoffersen 4y ago
  isn't "callback hell" a bit old fashioned now? With promises and async/await etc.
  - nivertech 4y ago
    Even with async/await it's still single-threaded. I might be mistaken, since I'm not up-to-date with the multithreading/concurrency/isolates in nodejs/V8. IMO async/await is error-prone and isn't an ideal programming model.
    - hnbad 4y ago
      > Even with async/await it's still single-threaded. That doesn't mean anything. V8 is single-threaded but Node.js I/O is non-blocking. The reason Node became popular in the first place is that companies started adopting it to fill the gaps in their existing infrastructure (e.g. Java) to offer "realtime" (i.e. web sockets or its experimental equivalents) communication. > IMO async/await is error-prone and isn't an ideal programming model. What's the point of unsubstantiated statements like that (btw "x is error-prone" is an empirical claim, so prefixing it with "IMO" just means "I can't back this up and don't care if it's true") other than stirring up pointless language rivalries? Just acknowledge that your off-hand comment about "callback hell" was anachronistic and don't try to come up with excuses to justify your preferences. I think Elixir is neat and hope it can see sufficient adoption for me to justify getting invested in it but that doesn't justify poopooing other languages, especially ones you admit not to have up-to-date knowledge about.
joshxyz 4y ago
Great thing for me is having nodejs bindings for the underlying c++ core is i get to iterate fast on nodejs. Any developer out there who have been fascinated by and have used socket.io should already be using this.
s6ro 4y ago
If anything, the article proves that when you want performance don't use Node.js - or more generally, abstractions have a cost. The actual library, as already pointed out, is written is C/C++ and bypasses Node for everything, other than providing an usage API layer. Its the same as claiming that Tensorflow is written in Python ;)

by par 4y ago

foepys 4y ago

The library mentioned in the article is C++ code that extends Nodejs and basically bypasses all of it. Nothing is making Nodejs special here. The Readme says: > µWebSockets.js is a web server bypass for Node.js that reimplements eventing, networking, encryption, web protocols, routing and pub/sub in highly optimized C++

fastball 4y ago

Well this isn't really NodeJS, it's written in C++. The whole point of Node is that it is a wrapper around the V8 JS engine (the one used in Chrome) that allows you to run JS specifically in a non-browser environment. This project is more an extension to Node (or as it is called in the GitHub README, a "web server bypass for Node.js). You do actually see the same kinda thing happening in other ecosystems, especially Python – something runs slower than you want it to (because Python), so you re-write it in Rust/C/C++ and hook into the extension system of the lang for a seamless DX. Off the top of my head things like `asyncpg`, `orson`, `uvloop` and esp relevant in this case `websockets` are all async libs that do this. Mildly tangential but as someone who has spent a lot of time making the Python backend for my startup run as fast as possible, I would recommend avoiding Python if performance is your primary concern.

akmittal 4y ago

Definitely possible to get similar or better performance using go, swift and rust. Python is slower in most cases so i dont think it would be possible using python(unless calling C from python)

josephg 4y ago
Yep. I'm also not sure if the server libraries in swift are mature & well optimized enough to handle millions of active websocket connections. Maybe someone with more swift experience can chime in! Whats the state of swift on the server these days?

nivertech 4y ago

C1M is not that impressive anymore, these days one need to do C10M;) Most of the work of accepting and holding concurrent TCP sockets done by the OS, not the language runtime. One can easily tune Linux kernel to 1M concurrent sockets. The real issues: memory usage per concurrent socket (idle or active), and ability to do something useful with all these active connections, e.g. send pings every 30s, or broadcast a message to all of them. I'm not sure NodeJS/C++ based system from this post will allow sending pings every 30s to 1M websockets, let alone to do something useful with them, beside some low-traffic or infrequent notifications (Of course one always need to perform realistic loadtests in order to answer these kinds of questions). Erlang/Elixir/BEAM have a relatively large memory usage per active socket, but it allows doing something useful with them under an easy to use programming model (read: no callback hell).

nkristoffersen 4y ago
isn't "callback hell" a bit old fashioned now? With promises and async/await etc.
- nivertech 4y ago
  Even with async/await it's still single-threaded. I might be mistaken, since I'm not up-to-date with the multithreading/concurrency/isolates in nodejs/V8. IMO async/await is error-prone and isn't an ideal programming model.
  - hnbad 4y ago
    > Even with async/await it's still single-threaded. That doesn't mean anything. V8 is single-threaded but Node.js I/O is non-blocking. The reason Node became popular in the first place is that companies started adopting it to fill the gaps in their existing infrastructure (e.g. Java) to offer "realtime" (i.e. web sockets or its experimental equivalents) communication. > IMO async/await is error-prone and isn't an ideal programming model. What's the point of unsubstantiated statements like that (btw "x is error-prone" is an empirical claim, so prefixing it with "IMO" just means "I can't back this up and don't care if it's true") other than stirring up pointless language rivalries? Just acknowledge that your off-hand comment about "callback hell" was anachronistic and don't try to come up with excuses to justify your preferences. I think Elixir is neat and hope it can see sufficient adoption for me to justify getting invested in it but that doesn't justify poopooing other languages, especially ones you admit not to have up-to-date knowledge about.

joshxyz 4y ago

Great thing for me is having nodejs bindings for the underlying c++ core is i get to iterate fast on nodejs. Any developer out there who have been fascinated by and have used socket.io should already be using this.

s6ro 4y ago

If anything, the article proves that when you want performance don't use Node.js - or more generally, abstractions have a cost. The actual library, as already pointed out, is written is C/C++ and bypasses Node for everything, other than providing an usage API layer. Its the same as claiming that Tensorflow is written in Python ;)