Maximum number of channels per connection?

[keagan...@gmail.com]

Hi,

I am interested in learning more about how the number of channels a subscriber subscribes to affects scalability and performance. 

Nchan says in their wiki "With channel multiplexing, subscribers can subscribe to up to 255 channels per connection". Is nginx-push-stream similar? 

Is it advisable to have clients subscribe to ~20-50 channels in a single connection?

If I needed a client to subscribe to 30 channels, lets say, is that fine to do on a single connection or would it be better to have them open several websockets each with 10 channels? Or would it be best to redesign the system so so many channels are not needed?

I know there is memory pressure on Nginx based on the number of channels you have (270 bytes/ channel). But is the number of channels per subscriber a salient statistic as well? Is there a large performance/memory difference between having 1000 channels among 1000 subscribers and having 1000 channels among 10 subscribers?

Thank you very much for your help!

-keagan

[Wandenberg Peixoto]

Hi Keagan,

I don't have a load test based on the number of channels a subscriber subscribes but I will try to answer your questions based on the structures that the module uses.

If you are only using one of the stream modes (not polling or long polling) the number of channels will change the amount of time to start the connection since the subscription is sequential, but after that makes no difference.

This time is influenced by the number of channels you are subscribing (m) and the number of channels already in the server memory (n). 

The complexity of this operation would be something like "m.n.log(n)".

Based on this information, is better to use fewer connections as possible. Of course, is up to you decide the number of channels that you need based on your application's requirements. 

Other than that, I guess that multiple WebSocket connections would make your app try to handle multiple concurrent events, which can be problematic sometimes.

Regarding the question about channels/subscribers performance/memory consumption, the only difference in the scenario you proposed is that fewer subscribers use less memory.

But, if you consider one channel with one or thousands of subscribers you have a difference on the time that takes for propagating a message since the delivery is sequential (on the same Nginx worker). 

Imagine that you have a fair distribution: 1 channel, 1000 subscribers, and 4 Nginx workers (resulting in 250 subscribers in each worker). So the first subscriber receives the message, then the second and so one until the 250th. Only after that, the first subscriber will receive a second message.

Hope that you can use this information to make your application and the module fits your needs.

Let me know if I can help in something else.

--
You received this message because you are subscribed to the Google Groups "nginxpushstream" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nginxpushstream+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[keagan...@gmail.com]

Hi Wanden,

Thank you so much for your response. I think that all makes total sense to me.

We are using 1 connection per client and trying to keep the channels per connection pretty low (3-10 channels/sub). It seems to be performing quite well even at 30k+ connections.

Thank you for your help and thank you for this module.

-keagan

To unsubscribe from this group and stop receiving emails from it, send an email to nginxpushstre...@googlegroups.com.