alexhultman

I definitely agree the Node.js universe needs to take a better look at using addons. My opinion is that one should only use JS for the application logic, which requires high productivity, and only (or mostly) implement core modules as addons. It makes sense to use JS where productivity matters and to skip it where performance matters.

The pipelining benchmark is identical to that of Japronto (another, very similar thing posted here on HN a few days ago). Japronto's repo on GitHub holds the wrk pipelining script used.

I haven't had the time to add configurations for every server tested (esp. Apache & NGINX) but the main point here is to showcase the Node.js vs. Node.js with µWS perf. difference.

> I've found it trivial to make Python perform on the order of dozens of millions of requests per second [...]

No, no you haven't. This is not a cluster of servers, this is one single thread serving 1 million responses per second. Inside of Node.js.

You don't consider a 60x performance overhead reason enough? And yeah, thanks so very much for flagging this post!

WebSocket++ was written at the same time as Socket.IO and performs about 30x better. I give credit where credit is due. I also criticize projects where criticism is due.

µWS is not a Socket.IO killer. In fact, you can use µWS as the low-level engine in Socket.IO.

Sadly I cannot (yet) present the pub/sub benchmarks of deepstream.io vs Socket.IO but I promise you: it will be hilarious.

Other projects that have been shown to outperform Socket.IO include SocketCluster, which use µWS as the default engine.

My keyboard would wear out if I listed everything wrong with Socket.IO. Simply put: it is one of the worst pieces of software I have ever stumbled upon. And the ratio hype-to-quality is off the charts. It's success lies in the fact that most users don't check their numbers and simply follow what everyone else is doing. Combined with the marketing of being "the fastest" which logically means "there exists no such solution in any universe, that outperforms it".

I would recommend WebSocket++ or libwebsockets (if you are not going with µWebSockets).

This is what happens when a GitHub repo accumulates critical mass: people just follow after with no critical thinking. It's like the emperors new clothes.

Thanks, I just finished the Socket.IO benchmark and wanted to show my findings (both in relation to my own project but also in relation to the existing alternatives) Socket.IO is simply a tremendous fuck-up no matter what perspective you have.

But can it run Crysis? ;P

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.

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

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.

If you don't like it, don't use 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.

I don't get it, why would anyone follow the advice of someone that is not actually hired by Google? That makes no sense at all. "Follow me, because..... because.... I WILL SUCCEED".

I've myself been interviewed by Google and yes, you cannot wake up an hour too late and go get a cup of coffee while simultaneously answering the questions in your pajamas (like I did). Sure you need to study some classic CS, but it's not really that overly difficult if you are a natural. They give you this list of subjects on which you are to self assess your skills so that you can get somewhat tailor made questions of what you feel strong in. Just go study basic CS stuff around those questions.

I failed because I did not have all the Big-O complexities and all the Unix syscalls in my head at that particular time, but you sure could go memorize them. It's all about passing those initial very basic tests so that they know you are worth their time - from that point you should get to show yourself a lot more.

But don't take advice from me, I'm not hired by Google.

That's sweet of you. Also, Node.js people will need Node.js 6.4.0+ for Windows support (until patches land in LTS).

Thanks, I can certainly help people with questions if they need help in writing a Python wrapper. I think that would be a good solution but it would need to integrate seamlessly with the rest of their app. Posting on GitHub would be a good start in this, or Gitter.

You can create a C binding and it does integrate with libuv.

libwebsockets is targeting the embedded world with a smaller code footprint (libc vs libstdc++). libwebsockets performs very good in memory and CPU time.

I can assure you, the short send optimization is not broken.

The server is async, so there is no blocking functions exposed.

It passes all Autobahn tests, meaning it properly handles close frames & pings etc.

Timers are used to force close connections. The C++ HTTP server does not currently time out, but the Node.js HTTP server does, so this is one issue that needs to be fixed, yes.

I want to thank all people involved in making this open source project possible. Things are by far not set in stone and this library has only been in development for about 2 months now.

We are working with SocketCluster to make µWS default in version 5, and I have gotten a lot of help from a lot of people during these months.

Thanks for support, I will be accepting PR's and receiving issues that we need to fix before making any kind of official stable release.

Also, try to ignore the hateful comments - these commenters build their cases on thin air, and if you actually do find anything you want to change - I will accept PR's that can be shown to improve the library.

Yes, my friend. This guy is trying to roast the library based on bullshit warnings that normal projects (Node.js as one example) explicitly disable. So if you want to make a case out of this, you will have to report this "issue" to Node.js developers also, because they also have a lot of warnings ignored by turning them of, simply because they are pedantic.

So you enabled pedantic warning level, and you got a bunch of pedantic nonsense warnings.

There is a reason for these not to be enabled by default.

* Unused parameter -> rly? Who gives a damn? * Use of old style cast -> Well I'm old style, get over it. * No previous prototype declaration -> Again, I do this if I want to. * Shadows field -> who cares? No me. * Cast increases required alignment -> Well, obviously the perf cost is not an issue here. * Etc, etc, etc

These are pedantic warnings. However, this is an open source prject and you are free to send me PR's whenever you want.

According to logic, this quote "yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production." is a personal attack. I get offended by this, personally. When I get offended, personally, I answer how ever I see fit.

Thank you, you will be missed. I don't know what to do without you.

Yes it would cause undefined behavior but empty() is checked before popping.

WARNING ----> NO OFFENCE:

You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while.

This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tcp_t. This is the level of optimizations we are talking about -> when libuv is considered too heavyweight...

When libuv becomes too heavyweight to keep up, having this discussion about how a Python async network library could implement similar performance is just purely ridiculous.

WARNING -> NO OFFENCE

Node.js has nothing to do with the performance of this server.

Toss a coin and it will land on someones holy ground..

My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.