alexhultman

I don't think so but Meatier (https://github.com/mattkrick/meatier) should receive uws as default engine since it build on SC, you could look into that but honestly I don't understand this project at all :P

Nope, only ws <-> uws :(

Yes, I use uv_poll_t instead of uv_tcp_t because of massive memory and performance differences.

Every decision made, has been made from a performance perspective.

1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x.

Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it?

Get over yourself.

Yes, Socket.IO really need to step up their game if they are going to have this kind of marketing:

"FEATURING THE FASTEST AND MOST RELIABLE REAL-TIME ENGINE"

Never mind the fact that one libuv tcp stream consumes more memory than one entire WebSocket in µWS...

Memory footprint and performance.

This implementation is way, way more lightweight. And it assumes that the buffer being queued has a struct Message in its head, so it doesn't have to allocate a node - one memory allocation is therefore skipped.

Also - this server passes the entire Autobahn with no fails, passes Engine.IO tests, Primus tests and exits gracefully with no Valgrind issues. Also, it builds with no warnings. Also, it has been running for weeks stable.

If you allocate the buffer as a char * you should delete it as a char *. Thank you for the kind words.

Yep, thanks for being one of the first adopters :)

Like mentioned, it works as an optional engine in Socket.IO, Primus & SocketCluser (in which it will be default in version 5).

No code change, swap when you feel lucky :P

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

I get this question quite often, here is a good start: https://github.com/alexhultman/uWebSockets/issues/56

I think the best solution would be to write a Python binding to µWS. You will not be able to implement this perf / memory footprint in Python itself.

There is nothing new brought to the table, feature wise. Same old ws interface, you keep your current code unchanged.

Swap require('ws') with require('uws') and see how it works for your code, report any issues if you need them fixed.

Well, of course there is a 20-30x perf boost, 10-40x memory improvement compared to ws (as the benchmark table shows).