What (error) message do your users see? Are they told that there are no free seats on the app or is the app just slow/unresponsive?
With your parameters Connect should put 10 users each unto each process until 18 processes serve 180 users. After that, the number of users on each process would increase to 20, serving a total of 360 users. That is much more than your estimate of 150 concurrent users, so I would be surprised if the users were to see a message about "no free seats".
However, it might be the case that a single process cannot serve 10 (or even 20) users. Keep in mind that if one user triggers some compute intensive action, all other users that are connected to the same process have to wait for that process to end. You can work around this by lowering Max connections per process or Load factor, but that comes at the cost of an increased memory footprint, since you will need more processes for the same number of users. An alternative approach would be asynchronous programming, e.g. using the
Another possibility is the memory footprint of the processes. Maybe the system has to start so many R processes for this app, each of them using a lot of RAM due to the loaded data. If your server runs out of memory, performance will deteriorate quickly. If you know when your app was slow, you can look for such events in the admin dashboard within Connect or any other server monitoring tool you are using. If it is a memory issue, you could increase Max connections per process or Load factor, but that comes at the cost of an increased user count and therefore CPU load per process. An alternative approach could be to not store the full data in memory. Tools like
duckdb or other database systems can be used to offload much of the preprocessing of the data, so that only aggregated or subseted data needs to be loaded into R. Of course, it depends on the prices use case if something like this is feasible.