I have developed fully functioning Shiny app and deployed it on my free account at shinyapps.io. Now I am looking to
Scale it 300 (potentially 1000) daily unique users
Add authentication
estimated usage avg 1hr/day/user
peak RAM 400MB
The resources I have found are mostly at least couple of years ago. What are the bulletproof (cost effective) solutions you Shiny developers use in 2023?
Is that the peak for the maximum number of concurrent users or is it for one user? Are users expected to be spread over all time zones or will the be concentrated in one (where everyone fires up the app at 10:30, for example? What’s the latency standard? Are users all high bandwidth, in which case latency is notable, or does transient server latency get overshadowed by persistence network latency.
The same provisioning that works fine with equal instantaneous load 24/7 is going to degrade with peaks unless it is way overpowered.
All these and others have to go into optimization, but good enough can do with less. T’were me, without knowing more, I’d spin up a shared on demand instance, install and log with a single unauthenticated user. Then use a bot to make 10, then 100 then 1000. If I found pegging out, I’d convert to a dedicated on demand instance and retest. Then double the RAM, etc.
Or, I’d use take the finished shiny app and implement it as a WASM app.
It is hard to say what would work best, but consider also if multiple users can share the same instance of the app or not. If yes, maybe the 400 MB RAM can serve multiple users as long as the data is same for all users (i.e. you can load it into memory once outside of the server function).
Have a look at this post as well to see how to set up session affinity on Heroku, that can provide you with the easiest scaling to find the level of resources you need.
After you have some insights and monitoring data, you can switch over to different kind of dedicated resource that can be cheaper on the long run (AWS EC2 with a load balancer).
What struck me looking at this (after opening the images in separate tabs to enlarge enough to make visible) is that major items are
There is some serious latency that will lead to keybanging by impatient users that will increase load.
Compute operations take a relatively long time, which suggests the logic may involve unnecessary looping or other opportunities exist for better performance
The next to last step on the cascade is very expensive for rendering. It's possible that some sort of templating approach might speed things up.