SocketCluster – WebSockets that scale to 100K messages per second on 8 cores | Hacker News Reader

SocketCluster – WebSockets that scale to 100K messages per second on 8 cores

github.com

93 pointsBukhariH24 comments

From their readme-

"The test was only set to reach up to 100 concurrent connections (each sending 1000 messages per second) - Total of 100K messages per second."

So they had only 100 concurrent connections.

Number of connections, message size, and frequency of messages sent are three main parameters to measure performance, and for some frameworks like Engine.IO, number of connections seems to have the biggest impact on performance (https://medium.com/node-js-javascript/b63bfca0539). It would be good to see the benchmarks with much higher number of connections, as non-blocking IO is usually why people choose Node.js platform.

Is 100K mps on 8 cores considered high for node/websockets microbenchmarking of the socket path?

That doesn't seem like much from past experience writing high-throughput messaging code, and all this is doing is spitting out length-framed messages to a socket.

Can you give some numbers of your past experience?

Not OP, but a solar flare can shoot 20 million packets per second..

http://www.solarflare.com/09-11-12-Solarflares-Industry-Lead...

You need to totally bypass the linux kernel to do this, and have high perf C or Java code...

That's raw network (TCP/UDP) packets, not WebSocket frames/messages. Plus that product is a solution to a hardware problem, not a software problem. It doesn't relate at all.

Just for anyone else who sees that and thinks "WTF": it's 20M PPS across two ports. (14,880,952 is the max for 10GbE.)

It's not high at all.

I have never worked with node though... so maybe it's ... sort of ... "fast for node". Not fast in absolute terms.

That's what I was thinking, too. That's merely around 13,000 messages per second per core. Rates like that weren't all that impressive on low end server hardware a decade ago, so I'd hope that it's even less impressive today when using more modern hardware (or even VMs).

We do not (yet) measure the performance of Websocket in our project (the TechEmpower framework benchmarks), but our "Plaintext" test is a rough analogue to a ping-pong test on Websocket. Our Plaintext test uses HTTP pipelining on a keep-alive connection. However, in our case, each request is sending a couple hundred bytes of HTTP request headers and receiving about the same in response HTTP headers prior to a "Hello world" payload.

We see approximately 600,000 of these HTTP "messages" per second on a i7-2600K 8 HT core workstation [1] from top performers such as Netty and Undertow and these top performers are network limited by our gigabit Ethernet.

We are using Undertow for a Websocket project presently and its performance there has been very good.

[1] http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...

I'd be expecting more in the realm of millions of messages per second, at least from a Java solution.

This is interesting, how does it compare to using nginx(or another proxy) in front of multiple socket.io instances on the same machine?

I wrote SocketCluster. I haven't tried that yet, it would definitely be interesting to test.

I'd be interested in seeing how difficult it would be to modify this to use multiple communication servers (redis, cassandra, etc) so that it can be scaled across multiple instances.

Would also be interested in seeing how many connections it could handle doing say 5-10 messages per second.

There's also sockjs (http://sockjs.org) which has some rather impressive benchmark results when using the python/tornado server with PyPy (http://mrjoes.github.io/2011/12/15/sockjs-bench.html). 155,000-195,000 messages per second on a single core.

It'd be nice to compare it with: https://github.com/automattic/socket.io-redis

I wrote an example application using it here: https://github.com/guille/weplay

How many simultaneous connections are you able to achieve?

Why does each worker need a seperate store process? It seems on an 8 core machine max worker count can only be 3 (1 master, 3 workers, 3 stores). If workers had in-memory stores -or at least connect to a Redis server-, with 4 more workers performance should increase.

node is single threaded

I'm aware, and what's the relevance? I didn't even mention threads.

You can't use more than 1 core with a unique node process. So they spawn n cores for n processes. With a multithreaded runtime, this would not be required.

Yes exactly. My suggestion was the application to fork (CPUs - 1) workers, ie. 1 master 7 workers, instead of 1 master 3 workers and 3 stores, and have workers manage their key-value stores. Apparently each worker don't need a store, see author's comment (https://news.ycombinator.com/item?id=7713561) so it looks good.

They don't. You can have fewer stores than workers. In the benchmark, we could in fact do with very few stores because they are not really used. I'm sure you could fiddle with the worker, load balancer and store count to get better performance (it depends on the system's requirements).

Do you think Golang can handle more connections than NodeJS?

Reply on news.ycombinator.com