Control number of users per worker

[DivadNojnarg]

Thanks for this cool tool.

Is there a way to explicitly say "1 want 1 user per worker max"?

[DivadNojnarg]

My observation is that when you serve 2 apps in a router context, each app has a different set of workers assigned, which means that if app 1 has some latency, it does not impact app 2:

Starting process 45533 for [/01_hello/]::Worker::1 on port 55905
[2024-10-30T08:59:22Z INFO  faucet] Starting process 45534 for [/02_text/]::Worker::1 on port 55906

However, for a single app you can't control which worker a user will be assigned, so 2 users connecting to the same route, can potentially be on the same worker and experience latency.

[andyquinterom]

@DivadNojnarg Hi David.

Good question. Since the router can have multiple workers per route (app), worker 1 under "/01_hello/" is different from the worker 1 under "/02_text/". They are completely separate R processes and they don't interfeer between each other.

Hope this answers your question.

---

In terms of limiting the number of users per worker, how would you imagine this working? What happens if you run out of workers?

[DivadNojnarg]

Similar to how it can be done in Posit Connect. Let's say having this set of parameters:

• max_processes: maximum number of R processes to allocate for an app. Limited by the system resources.
• max_users_per_process: maximum number of users a single R process can support. Default depends on how it is currently done with the load balancer.
• process_load: something between 0 and 1, 0 being "1 user per process" and "1 being max_users_per_process".

Running out of workers, assuming you set max 5 processes and 5 users per process so 25 concurrent users for a specific app¹, any extra user could see a warning message "This app has reached its maximum user capacity".

The use case would be an internal app where you know exactly the theoretical number of concurrent users who can connect. For 10 users, it's probably a better experience to have 10 processes with a single user, rather than having 5 users on 2 processes. Of course, we agree that for an external facing app, where you can't control the number of visitors, I would not advise doing so and leave the current defaults settings.

Footnotes

1. I am not advocating for developing under-optimized apps 😄, using async tools like {mirai} + ExtendedTask can solve most of the problems. ↩

[andyquinterom]

Similar to how it can be done in Posit Connect. Let's say having this set of parameters:

• max_processes: maximum number of R processes to allocate for an app. Limited by the system resources.
• max_users_per_process: maximum number of users a single R process can support. Default depends on how it is currently done with the load balancer.
• process_load: something between 0 and 1, 0 being "1 user per process" and "1 being max_users_per_process".

Running out of workers, assuming you set max 5 processes and 5 users per process so 25 concurrent users for a specific app1, any extra user could see a warning message "This app has reached its maximum user capacity".

The use case would be an internal app where you know exactly the theoretical number of concurrent users who can connect. For 10 users, it's probably a better experience to have 10 processes with a single user, rather than having 5 users on 2 processes. Of course, we agree that for an external facing app, where you can't control the number of visitors, I would not advise doing so and leave the current defaults settings.

Footnotes

1. I am not advocating for developing under-optimized apps 😄, using async tools like {mirai} + ExtendedTask can solve most of the problems. ↩

This sounds possible. I have two main concerns:

1. Denial of service attacks. How can we prevent a user (perhaps un-intentionally) from acquiring all the available workers and denying entrance to other users.
2. Should we recycle workers? I believe it is usually better to start workers and recycle them rather than starting and killing through out the life cycle.

If we figure this out I can make an RFC to work on this feature

---

PD: For the denial of service I would believe it still makes sense to use 1 worker per IP address. This would make it way harder for a single computer to deny service to others. The IP would acquire some sort of lock of the worker and only that IP could access that worker.