[ttt111222333]

> As http sockets in µWS build on the same networking stack as its websockets, you can easily scale to millions of long polling connections, just like you can with the websockets. This is simply not possible with the built-in Node.js http networking stack as its connections are very heavyweight in comparison.

I'm a bit confused by what's going on here. Are you saying the network stack required to do websockets is vastly superior to the network stack of http, and hence using a websockets network stack in http calls can produce superior results? (I didn't know the underlying networking would be different and any clarity would be helpful).

I'm not really understanding the differences but it is definitely interesting nonetheless.

[alexhultman]

What I mean with this is that any connection (socket) in Node.js builds on net.Socket which builds on uv_tcp_t which together requires a significant amount of memory (bloat).

A socket in the networking stack of µWS is far more lightweight (which already has been shown when it comes to µWS's websockets). The "HttpSocket" of µWS is about as lightweight in memory usage as "WebSocket", which is far more lightweight than net.Socket in Node.js.

One million WebSockets require about 300 mb of user space memory in µWS while this number is somewhere between 8 and 16 GB of user space memory using the built-in Node.js http server.

µWS is a play on its "micro" (small) sockets.

[azinman2]

I feel like "bloat" is thrown about so much these days, with little credence to actually defining it in a per situation context. It would be far more credible to me to not use such a handwavey term and instead talk about what the memory differences are, and why one might use much less memory than the other. Often times one person's "bloat" is another's necessary feature to accomplish their goals.

It's like saying Django has a lot of bloat in comparison to some super basic http lib, except it has all the features I'll need to build a non-trivial app.