Hello,
The main constraint I have is to not have room overcrowded.
I set that limit to 70 for 2 reasons.
-
Performance: Some users talk about Presence timing out when it goes over 500
-
Those list of joined users will be displayed in a UI (mobile app)
In the context of the app I’m building, I don’t need to return that many data.
On the other hand, yes I want those rooms to be as balanced as possible, because, still in the context of the application I’m building, those rooms are used to get users in touch.
So I don’t want an user to end up alone or only a few users to get in contact with (ideally).
What I should mention as well, is that I developed a background job “balancer” for the global counters (running every 20 seconds), which goes over the aggregated counters and broadcast to specific channels where to move when they become less crowded.
That works well as well, but the idea is to get those counters as balanced as possible as users are joining, rather than waiting for the balancer to do re-equilibrate the channels.
I’d love to see any details for that and if that indeed is a problem with large individual channels vs. many users no matter the spread over channels.
1 ) Are you saying that Phoenix Presence used on a channel of let’s say 10 000 users across multiple nodes would be the same as splitting those in 142 channels of 70 users or so ? (performance wise)
2)Let’s say for the sake argument that it does.
For my use case, I don’t need to return thousands of users to my UI, I only need a hundred or so.
Yes I could slice what Phoenix Presence returns but in the end, splitting those large number of users into small rooms allows to do some kind of “pagination”.
