We recently made the Socket.IO parser 300% faster.
The new underlying websocket server is extremely fast (check the benchmarks at https://github.com/learnboost/websocket.io/), and optimizations to long-polling are coming as well.
Is there anything people looking forward to these features should know to plan? Like, I was about to start doing some load balancing stuff soon. Is that a waste of my time and I should just work on the core logic and figure load balancing is just going to be made easier in the near future and I shouldn't waste my time with it? Or should I roll my own option for now and then just figure at some point I should be able to transition to something that performs better in the future?
Socket.io has a lot of bloat that isn't required if all you need is a simple Websocket communications. Please do not add long-polling to websocket.io, it's the wrong place to do that type of abstraction.
Not true. I continue to use https://github.com/Worlize/WebSocket-Node with great success.
9k messages/second on a single 3.3ghz VM with 1,000 connections seems quite manageable and isn't out of line with other systems I've seen that are written in Java, .NET, C++. 100ms is an eternity to wait for a response, however. That's concerning. Especially since that is the case at low message rates. I wonder if that is a function of how the client is acknowledging the received data, rather than the actual time the server is taking to send it back.
What was the limiting factor on the server for this test? I've seen instances where the VM network drivers get in the way in this scenario. Or, you could also be saturating the network bandwidth to the VM if it's a 100mbit interface. Or maybe it's just simply CPU limited in user time by socket.IO...
As for comparing to other systems, I think we're certainly at the same order of magnitude, but some rough tests a friend of mine ran made it seem like a java server/client pair could send about 4 times as many packets per second. But that's a somewhat unfair comparison - socket.io offers a lot more than simply raw packet transmission and that additional abstraction is going to come at a performance cost. But I think being on the same order of magnitude as a really low level approach like that is a good place to be at this level of maturity of the technology.
It would be super-awesome to see a profile of node.js when you run this test to see where the CPU is going. Is it something low level like the string parsing, buffer copying, socket writing, or maybe something higher level like some inefficient algorithm somewhere. As I read below that socket.io is focusing on performance now, I guess we'll know soon. :)