shinyapps.io settings

[lcolladotor]

Hi,

Based on the fact that the app loads about 2.5 GB of data into RAM to start off, plus looking at the metrics it seems like the app easily reaches 3GB sometimes even 4GB of RAM per user. I still haven't figured out the best set of settings to use for https://jhubiostatistics.shinyapps.io/spatialLIBD/ based on the documentation at https://docs.rstudio.com/shinyapps.io/applications.html#ApplicationPerformanceTuning and what I see in practice.

> pryr::object_size(sce)
2.08 GB
> pryr::object_size(sce_layer)
34 MB
> pryr::object_size(modeling_results)
20.3 MB
> pryr::object_size(sig_genes)
340 MB

## Total
> pryr::object_size(sce, sce_layer, modeling_results, sig_genes)
2.47 GB

We can run up to 10 instances, each of which can have XX number of R workers, with each R worker powering YY number of connections. Earlier I had XX = 1, YY = 1; however we easily ran into "503 resource unavailable" errors. So I now changed it to XX = 1, YY = 2 and added information on the landing page about how you can run the app locally with spatialLIBD::run_app(). Earlier today with a single instance, I could easily crash sessions (connections) if I opened 2-3 of them. And that's using xxxlarge, 8192 MB instances (the largest ones).

Anyway, if you have ideas of the best set of settings to use, please let me know.

Thanks!
Leo

[lcolladotor]

Part of an email I just wrote:

• Here's information about the shinyapps.io deployment settings shinyapps.io settings #2. That's where I explain a bit more the memory, the limits, the R workers * connections, all that. Briefly, we have 10 instances of 8GB each, each with 1 R worker and 2 max connections, where peak memory can reach ~4 GB per user from logs.
• Here's the chapter on the "golem" (https://thinkr-open.github.io/golem/) book on deployment https://thinkr-open.github.io/building-shiny-apps-workflow/structure.html#deploy although for now I've found it best to dive into the issues at https://github.com/ThinkR-open/golem/issues and even wrote one at App with user-provided data ThinkR-open/golem#364 when I first starting diving into this 8 days ago. 
• At https://github.com/LieberInstitute/spatialLIBD/blob/master/dev/03_deploy.R you can find the golem templates they include for deployment and the name of many of the functions they actually have. That's where I saw Heroku being mentioned although I'm not sure what it does/offer.

You can also run the app locally with:

## You'll need R 3.6.1 or 3.6.2 with Bioconductor 3.10 (current release)
install.packages('remotes') ## if needed
remotes::install_github('LieberInstitute/spatialLIBD')
spatialLIBD::run_app()

Between that and the potential dockerfile deployment option, maybe we can run it on AWS on a higher memory instance.

I'll email RStudio Support soon. Once I finish setting up my account for that.

[lcolladotor]

Request has been posted at https://support.rstudio.com/hc/en-us/requests/44981. Here's the actual request:

Hi,

We have a shiny app at https://jhubiostatistics.shinyapps.io/spatialLIBD/ that we are having some issues deploying as detailed at #2. Given the memory requirements of the app we are asking if there's a way to increase the number of instances, have larger memory instances or what other options you can help us with.

In more detail, the app requires loading ~2.5 GB of data in RAM to load and from tests we've seen that it can reach about ~4 GB per user. The largest component of the data is a Matrix sparseMatrix object, so it's already in low memory format to begin with (and portions of the matrix are converted to regular vectors for some plotting functions). We have access to the https://jhubiostatistics.shinyapps.io shinyapps.io Professional account, meaning that we can launch 10 xxxlarge (8GB) instances. Currently we set the max workers per instance to 1 with 2 max connections per worker; so 20 total users. We think that's about enough to have all 20 running ok without memory-related crashes (though 2 users could potentially go over 8GB of RAM). We would like to ask if it's possible to either request more xxxlarge instances than the current 10 (potentially 1 R worker & 1 connection per instance to avoid memory issues) as when we tested with 10 instances (1 worker, 1 conn) we quickly ran into 503 error pages.

We anticipate a high volume of users in the coming days as we will post a bioRxiv research pre-print describing the data behind this project. We at LIBD got early access to a new technology and will be the first ones to make this amount of data publicly available. Thus we anticipate quite a bit of interest from the research community in general as well as other R package developers (see the #spatial channel on the Bioconductor Slack workspace https://bioc-community.herokuapp.com/). That is, we anticipate having several dozen to maybe hundred concurrent users in the next few days. As the buzz decreases, then we'll have less concurrent users and eventually our current setup (10 xxxlarge instances, 1 R worker, 1 or 2 conns per worker) might be enough (except when we give present the work at conferences and many people access at the same time). Given that first impressions matter a lot, we would like to avoid as much as possible any 503 errors; or the other potential error (allow more connections but risk out of memory errors being very frequent). We do heavily describe that users can run the app locally simply with:

You'll need R 3.6.1 or 3.6.2 with Bioconductor 3.10 (current release)

install.packages('remotes') ## if needed
remotes::install_github('LieberInstitute/spatialLIBD')
spatialLIBD::run_app()

Thank you very much for your help. And please let us know if there's any information you need from us or how we can help you help us.

The code for the shiny app is publicly available at https://github.com/LieberInstitute/spatialLIBD.

Best,
Leo

Leonardo Collado Torres, Ph. D., Staff Scientist II
Lieber Institute for Brain Development
855 N Wolfe St, Suite 300
Baltimore, MD 21205
Website: http://lcolladotor.github.io

[lcolladotor]

Here are some updates.

• https://docs.rstudio.com/shinyapps.io/Troubleshooting.html has useful information. Maybe I'll tweak the settings a bit again, but likely not much.
• https://community.rstudio.com/t/shinyapps-io-503-errors/24683/4 also has useful info about a user with a similar situation to ours. Though no solutions really.
• From https://support.rstudio.com/hc/en-us/articles/214771447-Shiny-Server-Administrator-s-Guide and really from https://docs.rstudio.com/shiny-server/#custom-templates (the latest version of the same docs) we figured out that you can have a custom error template using shiny-server (Pro and non-Pro).
• We can deploy spatialLIBD at shinyapps with multiple names.

So our current plan, as we wait to hear back from RStudio is this one.

• Pay for an Amazon EC2 instance with a decent amount of memory (beyond the 8GB that we can get from shinyapps.io).
• There deploy the main version of the app where we will use the following error template https://github.com/LieberInstitute/spatialLIBD/blob/56088cc4302b97d3807377d74c090b30cff23998/dev/shiny-server-files/error.html (built using js4shiny) that mimics https://github.com/rstudio/shiny-server/blob/master/templates/error.html.
• Our template will point to the main app website + a 3 mirrors deployed through shinyapps.io. That way if users try to access the main app website they will get a more informative error than the default one.