Why add subscription for each room?

[2fours]

Trying to migrate from 0.9x to 1.x. There was a massive issue in 0.9x where 5 extra channels would be subscribed to in redis each time a new client connected: socketio/socket.io#1371

Looking at the code for socket.io-redis it seems like a similar problem is going to occur as each client creates a new subscription for the room.

 Redis.prototype.add = function(id, room, fn){
    debug('adding %s to %s ', id, room);
    var self = this;
    Adapter.prototype.add.call(this, id, room);
    var channel = prefix + '#' + this.nsp.name + '#' + room + '#';
    sub.subscribe(channel, function(err){
      if (err) {
        self.emit('error', err);
        if (fn) fn(err);
        return;
      }
      if (fn) fn(null);
    });
  };

Once we start getting into thousands of concurrent connections how is this not going to be an issue again? Am I missing something? Wouldn't it be better to just subscribe once for each redis client and do the multiplexing in code rather than via redis subscribe/unsubscribe?

[2fours]

Looks like before this commit 800ef74 socket.io-redis was using a single wildcard subscription when the redis client was created and not subscribing/unsubscribing for each socket client that connected/disconnected, which in light of socketio/socket.io#1371 seems to be the better approach. How is 800ef74 an optimization?

[2fours]

eg: https://github.com/surespot/socket.io-redis/commit/93b923848a94006023611e1dd4b69686fd96650e. (I'm using a passed in ioredis client so there are some changes there).

[darrachequesne]

Hi @2fours. This change was discussed here #46.

The cost of additional subscriptions does seem to be largely balanced with the multiplexing done at redis-level. Did you experience some issues with that?

[2fours]

It would seem to depend on the use case. In my use case each socket creates a room (so 2 rooms or subscriptions per connection - 0.9.x would create 5). Once you start getting into thousands of concurrent redis subscriptions - and adding and removing them constantly you start having problems with redis CPU utilization. For my use case it is better to publish to all nodes and each node sort it out. I suppose a way to tune the behavior could be beneficial. The test (https://github.com/koszta/socket.io-perf) doesn't really represent the use case where thousands of sockets and thus redis subscriptions are being created and destroyed continuously.