The day NodeJS lost a battle vs. Ruby EM
I really like NodeJS, when I joined my current company, first thing I did was starting to introduce Node based services into the production environment. I like NodeJS and I don’t buy “callback hell” concerns, the eco-system is amazingly vibrant, and it’s just nice place to see little things being created and moving so fast.
TL;DR;
I re-wrote a socket.io based server using EventMachine, em-sockets and native websockets on the client, this solved the issues requiring a restart of the server every 6 hours and took both CPU and memory levels to about 50% (memory leak aside):
The details:
And so, when tasked to create a chat like experience in our website, Realtime Web, Node was just about the obvious choice. Reading many resources (such as https://medium.com/@denizozger/finding-the-right-node-js-websocket-implementation-b63bfca0539) , looking at APIs and feature set, I ended up using Socket.io ver 1.2.1.
The requirements were simple:
- 10K or so concurrent users (the websocket based feature is used in a small part of the site).
- Should be able to broadcast in a 1:1 message (so not really chat rooms, and more of Instant Messaging).
- Be able to publish messages to specific users from the server, e.g. find a user by it’s ID/username and not by socket identifier.
Simple enough…. or not. The served leaked like mad. really.
Stackoverflow Question remained abandoned, github issue unanswered and the same goes for the IRC channel question.
I went ahead and created heapdumps of the node process, everything was pointing to native NodeJS allocations, dead end for me.
And so, I went ahead and recreated the service (100LOC or so) using EventMachine & em-websockets, to improve websocket stability on the client, I simply wrapped it using reconnecting-websockets.
I was totally shocked to find that this is the state of websockets in NodeJS land and but I somehow hope I’m soon going to learn what is that wrong turn I took..
I’d appreciate further inputs.
@avnerner / @github - AvnerCohen
