Consider using N Redis connections

[codesections]

Since Flodgatt began as a port of the Node streaming server, it follows the same general architecture for connecting to Redis. In particular, it opens a single client connection and subscribes to all channels on that connection. It then sorts incoming messages and distributes them to WebSocket (or SSE) clients.

However, I am concerned that this is re-implementing some of Redis' pubsub functionality in a way that is both unnecessary and, potentially, slower (presuming that Redis' code is as optimized as I believe it to be). In particular, Redis supports much higher numbers of client connection (the default is 10,000, and Redis seems to expect that each client will separately subscribe to the specific channels relevant to it. Adopting this architecture would involve opening a new Redis connection for each channel Flodgatt subscribes to, rather than a single connection for all channels.

The disadvantage is that we'd have the overhead of additional TCP/unix socket connections (both for Flodgatt and for Redis). The advantage, though, is that Flodgatt would save the work of re-sorting the messages in the different channels. It's not immediately clear to me which of these effects is larger, but I believe testing the multiple-Redis-clients would be worthwhile.

[Gargron]

At first the Node version was opening a new Redis connection per client but that created performance issues. That was long ago, I don't have any details, but it doesn't seem like a good idea to me. Maybe a fixed-size connection pool, but I feel like that's not really a bottleneck in the Node version at all.