It depends on how it's implemented. I used node.js to implement the websocket-based real-time aspects of my startup, Worlize, a graphical avatar-based chat platform where everyone can create their own chat world.
I use a sharded approach where each room is assigned to a random node.js websocket server when the first person enters it, and it's unloaded when the last person leaves. Just spin up more websocket servers to scale.
We have a hybrid platform with the website running on Ruby on Rails (REE 1.8.7, Unicorn, fronted by Nginx), and the real-time interaction handled by Node.js. I can tell you that the RoR servers fall over LONG before the Node.js servers even begin to break a sweat.
The two aren't necessarily the same kind of thing. WebSocket-Node is a low-level WebSocket framework. It supports both text and raw binary WebSocket messages. Socket.IO is not a WebSocket library, but sits one level higher on the stack. It's an abstraction layer that supports many different transports and overlays its own messaging semantics. For example, WebSocket-Node could theoretically provide the WebSocket transport for Socket.IO.
If you want WebSocket specifically, and don't care about falling back to long-polling techniques, or you want something that allows you to use true binary messages, look at a WebSocket library rather than an abstracted communications library like Socket.IO.
I use a sharded approach where each room is assigned to a random node.js websocket server when the first person enters it, and it's unloaded when the last person leaves. Just spin up more websocket servers to scale.
We have a hybrid platform with the website running on Ruby on Rails (REE 1.8.7, Unicorn, fronted by Nginx), and the real-time interaction handled by Node.js. I can tell you that the RoR servers fall over LONG before the Node.js servers even begin to break a sweat.
edit: Link to Worlize if you're curious: https://www.worlize.com/ Our Node.JS WebSocket Library: https://github.com/Worlize/WebSocket-Node