uWebSockets 0.10.0 | Hacker News Reader

uWebSockets 0.10.0

github.com

123 pointsalexhultman27 comments

We are using uWS for our platform which is completely written in native C++.

I haven't tested the scalability to a million clients, but I have no reason to doubt it could handle it.

On the other hand, I have tested with 20k clients each sending 100 x 128 byte messages a second.

So I've tried pumping 2 million messages a second through our platform (which is at the envelope of my expected load), and the server just sits there and takes it. At these levels saturating the network interface is the main issue.

I've also tried it in single core, 4 core, 8 core and 20 core threaded configurations. Everything works as it should and contention is quite minimal.

The ability to achieve that over WebSockets is largely due to the work Alex has done (and continues to do) to squeeze every last ounce out of the stack.

As far as I'm concerned uWebSockets 0.10.0 is rock solid and at the point where using it in production is totally fine.

I can totally recommend it.

Congrats on the release Alex and thanks for the lib!

Did you also perform some tests with slow clients (or ones that do not receive data at all)?

These are the situations where it usually gets a lot more interesting. E.g. if the library just buffers messages all the way until they can be sent you might get out of memory sooner or later.

Ah well we have high level policy to deal with obnoxious clients. We will forcibly boot a client if it exceeds certain limits. This is imposed at the application layer.

But no I haven't explicitly tested with thousands of leaky clients.

You can register callbacks to the send calls so that you can keep track of the built up "to be sent" message queue.

I like it.

All the nice optimizations that you only can do if you know what's happening in the background.

I read post about how Bluebird Promise implementation is more efficient than others and it was basically stuff like storing state as binary flags instead of boolean vars etc. pp.

This is awesome: when one clicks on "Language Details"...

  Makefile 1.2%   CMake 0.8%   QMake 0.4%

That is a highly optimized build process.

congratulations, amazing release. Very much looking forward to working together on https://deepstream.io/

Can I ask: how do you guys fund stuff like deepstream.io? Do you develop it for specific projects?

we're working on building a new kind of realtime data platform. The aim was to base it on a powerful open source core and release that first to alleviate concerns around vendor lock-in and third-party risk when using a PaaS offering.

I think the GP wanted to know: How do you finance development like this? As in, it seems like a lot of work, how do you sustain yourselves financially while noone is (yet) paying for using the fruit of the work?

It's a good question. Going down that route takes a significant amount of time before one can expect the first paying user. We've originally funded it out of our own pocket and later raised VC funding for the project as well

http://venturebeat.com/2016/04/07/deepstreamhub-raises-1-mil...

Do you have any performance numbers for other non-Node WS libraries, e.g. Go (stdlib and gorilla), Rust (ws-rs, mio-websocket etc), Python, Ruby? Would be super interesting to see!

Doesn't really answer your question directly, but this was posted fairly recently.

https://hashrocket.com/blog/posts/websocket-shootout

I've used websocketpp in the past (in C++), with fairly good results, but uWebSockets is in a whole other league; especially in a multi-threaded server.

That's cool. Yeah WebSocket++ is a really good project and I do respect the author (I used it as point of reference when building µWS). So if WebSocket++ beats all other implementations by a large margin then µWS would obviously beat those other implementations too.

Congrats for this achievement. For anyone using this in Node.js I strongly suggest to run your own benchmarks as uws is no way 47x 18x 33x and 2x times faster/more lightweight than ws. Also check how the improvements are obtained.

We moved to using uWS for deepstream.io 1.0 release and had great feedback from the community. To literally quote a user in production: 'After we upgraded to deepstream 1.0 we are seeing that the resource consumption is about 50% of what is was before so we still have growing space on our servers'. This was for the 0.7 release so I'm excited to see if 0.10 reduces this even further.

Yes, for 100k connection, using Alex's own benchmarks I saw that uws is up to 2x faster/more lightweight than ws except for the short message throughput where uws really shines and is up to 10x faster. It is a lot, don't get me wrong but the numbers on the README are obtained comparing the C++ server with ws which is totally wrong imho.

What do you mean when you say ws? Isn't uws just a library for ws?

`ws` is another popular WebSocket implementation for Node.js

WebSockets is the protocol, ws is a lib implementing it.

uws is a reimplementation of the ws interface, using fewer resources and providing better throughput.

Call me when you can get 1 million concurrent connections using 1.3 GB of user space memory with ws.

Hint: at 500k ws consumes all memory in my computer and the GC stalls are constant. My system start to freeze and my mouse cursor is no longer responding.

I can have 1 million connections with uws at the same time I'm watching cat clips on youtube, listening to spotify and having my complete IDE up and running.

For 100k connections your own benchmarks showed a different story. Now I didn't try with 1 million and I guess it gets worse so I trust you but I can try with removing the upgrade request, the event emitter, etc from ws to start at least with a fair comparison.

If you don't like it, don't use it.

It's your idea of transparency which I don't like, not your project.

A million connections into the computer that you work on? Are these bot net connections, or do use your machine as your server?

I test the user space memory scalability by connecting 1 million localhost connections on the same machine.

Btw, 1.3 GB is for the Node.js addon - the native server does 1 million connections using less than 300 mb of user space memory.

Reply on news.ycombinator.com