How do concurrent shinyapp users use memory and disk space on shinyproxy and shiny server?

Question

I have hosted my dockerized shiny app on a shinyproxy server on a virtual machine (16G memory and 100G diskspace). The app is intended for over 20 concurrent users. To my knowledge, the way shinyproxy works is it creates one docker instance for each user. So in theory they should not interfere with each other.

My question is about how concurrent users consume server's memory and disk space.

1. To make the app more responsive, my app load all my data into memory. Does every instance has its own copy of the data? Say, if my data loaded is 100 mb. For 20 concurrent users, the server memory has to be at least 2GB just for data loading? If each docker instance is 1GB, then total memory on server needs to be at least 20GB for 20 concurrent users? Does it work that way?

2. What about shiny server pro? If I host my app on shiny server pro, instead of shinyproxy, does the app on server just load the data once and every users can access the data with their own sessions? Do users see their session slowing down when certain number of concurrent sessions opened?

I'm new to shiny app deployment. Appreciate it if anyone can clarify me on these concepts.

Answer 1

For Shiny Proxy, to the best of my knowledge, yes, 20 users will spin up 20 containers, each taking up 1 GB of memory¹.

And, as each of the 20 users are isolated in each of their containers, whatever you do in global.R or outside of the server-function, users (mostly²) won't affect each other.

There are options for sharing memory between docker containers, but that is pretty advanced stuff (see this article).

Depending on the data structure of your pre-loaded data, you could consider moving the data into a database, that you pull data from when required. This could be an SQLite file in a mounted volume, or spinning up a docker container with MySQL on your machine alongside ShinyProxy. If your data is not well-structured for SQL databases, there are options for so-called "NoSQL" databases (no experience there).

Finally, if you do have to pre-load the data at instantiation of each user, try to cut it down to a bare minimum and streamline it as much as possible. If your data is e.g. hierarchical, you could consider only pre-loading the top-most levels and then load lower levels when required (e.g. with futures and promises). Similar advice is applicable for other data types - load only what is needed, trim of the fat (do you really need that data ting from start?), and perhaps some of your pre-calculations could in fact by calculated on-the-fly, when needed.

Footnotes:

1: Note that docker containers only take the memory they require, they don't allocate a chunk of memory just because they started.

[2]: I have however noted that I visited an app in two different tabs in Chrome were redirected to the same container. So users might not always be isolated.