
Websocket Shootout: Clojure, C++, Elixir, Go, Node.js, and Ruby - blahedo
https://hashrocket.com/blog/posts/websocket-shootout
======
chrismccord
Phoenix creator here. At the very least, this post needs to include the
following points:

\- Phoenix Channels is a higher-level abstraction over raw WS. We spawn
isolated, concurrent "channels" on the underlying WebSocket connection. We
monitor these channels so that clients can detect errors and recover
automatically without dropping the entire connection. This contributes to
overhead in both memory and throughput, which should be highlighted with how
Phoenix faired in the runs.

\- Phoenix channels runs on a _distributed pubsub_ system. None of the other
contestants had a distribution story, so their broadcasts are only node-local
implementations, where ours is distributed out of the box

Phoenix faired quite well in these runs, considering we are comparing a robust
feature set vs raw ws/pubsub implementations.

~~~
ericlavigne
All interesting points. Even without them, Phoenix does great in this
benchmark.

My takeaways from this article were:

1) Phoenix and Rails are clear winners on API.

2) Rails performance is unacceptable, which makes its nice API irrelevant.

3) All others are good enough that if I wanted to choose them for other
reasons, this article wouldn't stop me.

------
easong
Some discussion on the elixir subreddit a few days ago:
[https://www.reddit.com/r/elixir/comments/50nvhg/websocket_sh...](https://www.reddit.com/r/elixir/comments/50nvhg/websocket_shootout_clojure_c_elixir_go_nodejs_and/)

Of note is that of these, I think only the elixir and ruby (?) solutions are
distributed. Additionally, Phoenix channels are doing a lot of work that the
other solutions aren't.

------
onestone
Should have used
[https://github.com/uWebSockets/uWebSockets](https://github.com/uWebSockets/uWebSockets)
for Node.js, if performance was the objective.

~~~
abritinthebay
There's a lot that could be improved about the Node one.

The library and the the lack of clustering (so you can compare apples to
apples) are the main two.

Honestly? Running at 39% of the connections on one core is pretty impressive.
Especially with its low memory footprint.

~~~
frogglet
I'm not a node.js dev so I might be wrong here, but I imagine clustering would
complicate the broadcast, no? I was under the impression that communication
between the nodes of the cluster can be a pain.

~~~
tracker1
In a way yes, you'd need a control channel to centralize the broadcast to the
other processes. In more common use cases, Redis is used in conjunction with
node for these types of things. There are relays for redis with sockjs,
socket.io and others to make the setup/configuration a bit easier to work
with.

------
phodo
Nice article. Not trying to start a subjective debate on languages/
technologies, but it did seem odd they would include a language like ruby but
not python, c#, or java / scala.

~~~
jsmith0295
I mostly thought it was odd that of all of the JVM languages they included it
was Clojure. Ruby sort of makes since given that Rails recently included
ActionCable.

~~~
cwyers
Yeah, not having Scala or Java but having Clojure was strange to me. I would
be curious to see how a CLR language (C# or F# mainly) fares relative to the
JVM.

~~~
pcunite
I think C# would have done well, based on IOCP.

------
chaotic-good
With C++ one can go far further than that. It's the matter of time spent on
the solution. With all that other languages there is a performance ceiling
that can't be breached.

------
seniorsassycat
Is single threaded node was 39% I wonder how a clustered node app would
compare.

~~~
abritinthebay
Plus with an efficient lib as well. They certainly didn't use a very
performant one.

------
SNvD7vEJ
Odd there were no mention of Java.

Both high speed and simple to develop :

[http://docs.spring.io/spring/docs/current/spring-
framework-r...](http://docs.spring.io/spring/docs/current/spring-framework-
reference/html/websocket.html)

[https://spring.io/guides/gs/messaging-stomp-
websocket/](https://spring.io/guides/gs/messaging-stomp-websocket/)

------
zealsham
Using the cluster module for nodejs will make it almost the fastest and when
we add activities like reading from a database nodejs asynchronous pattern
beats everybody

~~~
socmag
ahem, apart from C++

~~~
tehlike
Citation needed. Not that i object to the fact that c++ is usually faster :)

~~~
socmag
That was the citation :-)

Seriously though, Node is written in C++ and is a single threaded interpreted
/ Jitted / Garbage Collected Virtual Machine which has to jump through
trampolines and layers of abstraction to call system services.

While it might be very efficient at what it does, it isn't as close to the
machine as a native C++ application.

One asynchronous WebSocket server written in C++ can run rings around one Node
WebSocket server.

If the premise is that to mitigate this we can set up an entire cluster of
node servers that will beat the C++ server, it follows that we can set up an
entire cluster of C++ servers that would be even faster.

C++ is faster in every regard. There is no "usually", about it.

If we are talking about some metric like programmer productivity, sure
sometimes it takes more effort to write code in C++ to achieve what may take a
single line in Node.

~~~
tehlike
Ok let me rephrase: The speed benefit of C++ not always matters. At Google
scale, sure. For most intents and purposes, probably not.

Otherwise, totally agreed.

~~~
socmag
I use node quite a lot, mostly for prototyping, demos and where I just plain
don't have the time or need to use something else. I have no problem with node
as an application development platform.

Right tool for the right job is fine

The trick is to minimize aggregate kWh of energy use per unit task. Sometimes
that means ordering a take out, and occasionally baking a pie.

A lot of the time I'm in the position of buildng upstream tools and platforms
for people downstream, so whatever I do has a direct impact on their
performance. The way I look at it is it is my duty to make them look good.

I do take that a little far though on occasion. Shipping is a feature too of
course. Heh.

------
pcunite
"C++ offers the best performance ..."

Yep

~~~
tracker1
At the cost of the most complex implementation.

