I’ve got an app that I am deploying to ShinyProxy. It is largely low CPU utilization, except when the users trigger the generation of an output. As such, concurrency is acceptable, but limiting collision of those output steps is ideal.
So, my question is: how are seats assigned across available containers?
At the extreme, if I ran a setup similar to the Affordable Shiny app hosting for 500 concurrent users with seats-per-container: 10 and both the minimum-seats-available: 500 and max-total-instances: 500 giving a static 50 containers, would:
- Container 1 be filled to 10 users first?
- Each of the 50 containers get one user until all have at least one, then each get a second?
- Round-robin assignment (so, give the 101st user to the first container, even if both users assigned to container 5 have already dropped)?
- Lowest user-count (randomly assign to one of the containers with the lowest user count)?
- Lowest resource utilization (assign to the lowest CPU and/or RAM container)?
- Something else?
For a more complex situation, like the last example here with minimum-seats-available: 3 and seats-per-container: 5, how would these be affected? After the first three users are assigned to container 1 and container 2 is triggered, where are the next two users assigned (assuming no disconnections)?
There is a clear balancing act here between spreading out the users across containers and concentrating them so that containers can be scaled down. As we scale, I am hoping to understand this behavior so that I can manage it.