Socket.io: Count of connected clients/sockets

+1. I think in my case this is one last issue causing memory problems (growing until segmentation fault).

Yep, crashes about twice a day with a segmentation fault here.

its noted in the "documentation":
http://labs.learnboost.com/socket.io/

under Socket.IO Node.JS server / Listener section (do an in-page search for "splice"). To quote:

"An array of clients. Important: disconnected clients are set to null, the array is not spliced."

To make it from thought to code to documentation means there has to be some reason why disconnected user's aren't pruned from this array, I just can't guess what that reason is. Best case scenario is that it makes keeping track of CONNECTED users a pain, and at worst is contributing to a lack of stability in a node.js/socket.io server implementation.

Marked as performance bug.

i have the same problem.

and i make my number base on some var with i +1 during connect event and -1 during disconnect. (so this is not null problem)

Usercount:

https://skitch.com/tomekotomek/f4867/dock

CPU:

https://skitch.com/tomekotomek/f489w/dock

MEMORY:

https://skitch.com/tomekotomek/f4eyy/graph.php-747x374

BTW.

it is more then performance problem it just lower our up-time to less then one week.

The way I figured how to do this was to use a Redis set of the client ids, add on the socket.io connect and remove from the set on disconnect. SCARD command gives you the # of clients connected and SMEMBERS all the ids.

yeah the array needs to cleared or a better way needs to found to hold clients.

+1

+1

+1
This is definitely more than just an array length issue.
Incrementing and decrementing a counter on connect/disconnect will still result in an ever increasing counter.

+1

+1

+1

+1

+1

Has anyone tried to isolate this to the various transports? I.E. See if it works the same in
websocket, flashsocket, xhr-polling, etc.

This is definitely an important issue as we can't leave the server running consistently without a restart. I can't even go a day without at least one restart as memory continues to grow. NOTE: In node 0.4.* memory is MUCH BETTER for me.

+1

i discovered the same problem - my memory just gets filled up. about 1 mb / per minute

with about 1500 sockets which reconnect due to clicks on the site havy.

it has to be restarted daily because of the memory leak

L2C FAF IT RTFM!!!
░░░░░▄▄▄▄▀▀▀▀▀▀▀▀▄▄▄▄▄▄░░░░░░░░
░░░░░█░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░▀▀▄░░░░
░░░░█░░░▒▒▒▒▒▒░░░░░░░░▒▒▒░░█░░░
░░░█░░░░░░▄██▀▄▄░░░░░▄▄▄░░░░█░░
░▄▀▒▄▄▄▒░█▀▀▀▀▄▄█░░░██▄▄█░░░░█░
█░▒█▒▄░▀▄▄▄▀░░░░░░░░█░░░▒▒▒▒▒░█
█░▒█░█▀▄▄░░░░░█▀░░░░▀▄░░▄▀▀▀▄▒█
░█░▀▄░█▄░█▀▄▄░▀░▀▀░▄▄▀░░░░█░░█░
░░█░░░▀▄▀█▄▄░█▀▀▀▄▄▄▄▀▀█▀██░█░░
░░░█░░░░██░░▀█▄▄▄█▄▄█▄████░█░░░
░░░░█░░░░▀▀▄░█░░░█░█▀██████░█░░
░░░░░▀▄░░░░░▀▀▄▄▄█▄█▄█▄█▄▀░░█░░
░░░░░░░▀▄▄░▒▒▒▒░░░░░░░░░░▒░░░█░
░░░░░░░░░░▀▀▄▄░▒▒▒▒▒▒▒▒▒▒░░░░█░
░░░░░░░░░░░░░░▀▄▄▄▄▄░░░░░░░░█░░
░░░░░░░░░░░░░░░░░░░░▀▀▀▀▀▀▀▀░░░

I just turned off the flashsocket transport server side and memory usage AND cpu usage is SO MUCH BETTER. Can anyone else try that out and see if that helps?

+1

I take it back, CPU IS BETTER but memory still slowly leaks. I assume this is because the flash policy server gets turned off?

Please stop bloating the feed with "+1", this is neither google plus or facebook...

man i got to do it +1 to that

there is also a Disable notifications for this Issue below

In my case, socket.manager.closed, socket.manager.handshaken is more than socket.manager.open. and I do not know how to clear the useless connections

EXACTLY the same here. We have to restart the server so many times per day, because the connections eats more and more memory until we run out of 4GB memory.
I will be very happy if this issue resolves, because I can not continue to use socket.io if I have to restart every few hours. (We have about 2000 online users at the same time, connecting and disconnecting)

I'm using socket.io 0.9.10 and the following code to determine the number of sockets:

var socketIO = require('socket.io').listen( .....
...
var numberOfSockets = Object.keys(socketIO.connected).length;

Not sure how accurate this number reacts to the various edge-cases, but 'til now it seems accurate: every browser connecting increases the number, every browser closed decreases it.

is there something wrong with this approach?

Setting aside the counting issues (which can be worked around) - the memory issues are pretty brutal here. Is there any hope of this being fixed in the future? It means long-running, high activity socket.io deployments are very difficult to manage.

Alternatively, does anyone know about forks out there that have this issue fixed?

The issue is related to the code bellow (taken from socket.io 0.9.10):

  SocketNamespace.prototype.clients = function (room) {
    var room = this.name + (room !== undefined ? '/' + room : '');

     if (!this.manager.rooms[room]) {
         return [];
     }

     return this.manager.rooms[room].map(function (id) {
         return this.socket(id);
     }, this);
  };

the method this.socket(id) creates new instance of socket, so using that on every socket connect would produce memory leak.

@dknaus provided excellent workaround to that ;)

@outbounder Can you point out what that excellent workaround actually was? Because all I see in this thread is an active socket count

@marksyzm

 Object.keys(socketIO.connected).length;

this is valid only if you have store attached to socketio. otherwise the only way around is to count them by custom logic like so:

 io.on("connection", function(s){ 
   connectedCount += 1; 
   s.on("disconnect", function(){
     connectedCount -= 1;
   });
 });

@outbounder but I thought the point of this bug is to fix the memory leak issue with sockets not disconnecting? Am I missing something?

memory is bleeding out of somewhere see

https://github.com/LearnBoost/socket.io/issues/1015

https://github.com/sockjs/sockjs-node/issues/81

https://github.com/joyent/node/issues/2328#issuecomment-3190337

Unsure if its websocket related or node related or both

sockjs is having similar issues - which means it could either that socket.io and sockjs use the same ws lib, which has an issue with node - or its just a general node isssue

+1

This is still happening to me in production. I don't even have that many connected clients, really - 100-200 at peak. Processes are just running out of memory and hanging or dying. Is anyone working on this memory leak? How can I help?

As far as I can tell, this has been a known issue for ages and everyone with aspirations of actual deployments has moved off socket.io. There's been no movement on this issue, and the engine.io doesn't seem to mess with the transport cores at all, so there's no reason to expect that to ever fix this either.

Honestly, I've been looking for evidence that ANYONE deploys vanilla socket.io in production with a websocket transport active and haven't found any reliable reports. Trello is a high profile user, but they've admitted to using some sort of patched version which isn't released and only uses the websocket transport (at which point, why use socket.io at all?). I've moved off socket.io entirely because it doesn't seem like this is going to change anytime soon. I can't promise sockjs has no problems, but I'm positive it doesn't fail nearly as rapidly as socket.io does if you join/leave a few thousand clients.

I was just wrestling with what I think is this issue, on my own socket.io/redis app, on Nodejitsu. It definitely seems like it's socket.io's Redis store. I'm going to switch to SockJS and write my own Redis management, I think.

Chat logs of me working through it in the #nodejitsu support channel:
https://gist.github.com/4146668

+1

Is it me, or does socket.io not use redis any more?

How about adding this.store.publish('disconnect', id); to Manager.prototype.onClientDisconnect
as suggested here: https://github.com/LearnBoost/socket.io/issues/831

Will there be any problems adding this line?? I like to know.

Second that?

+1

+1

Anyone?

Any movement on this issue? I'm hoping to deploy in the near future and would really value any insight that people with production deployments have on this issue.

Fix above worked for us ... load dropped significantly
On Jun 4, 2013 11:01 AM, "patrickod" [email protected] wrote:

Any movement on this issue? I'm hoping to deploy in the near future and
would really value any insight that people with production deployments have
on this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com/LearnBoost/socket.io/issues/463#issuecomment-18927408
.

Disabling flash socket support? The documentation says that this is now done by default.

I've never faced this issue but I'm still in development and benchmarking. Has this been sorted out?

You tell us. You are doing bench-marking. :D

On Thu, Jan 23, 2014 at 7:07 AM, Maziyar Panahi [email protected]:

I've never faced this issue but I'm still in development and benchmarking.
Has this been sorted out?

—
Reply to this email directly or view it on GitHubhttps://github.com/LearnBoost/socket.io/issues/463#issuecomment-33126062
.

You tell us. You are doing bench-marking. :D

Honestly I haven't noticed dropping in large numbers. I've seen few connections dropping after 5 6 minutes when I connect 1000 users at the same time but they reconnect really fast and I have over 10K messages per second to all the users. So I think my EC2 instance (m1.large) just not strong enough to keep them all alive without dropping few.
I was wondering whether I'm gonna face this problem in future. Mine is just dropping few and reconnecting them in stress test. After disconnecting all I can see clients number drops into 0.

+1

I've had no problems with all this since 10.11... I would possible put it down to using ubuntu 10.10? Either way, seems okay now.