Cost of Scaling Shiny to 300 Authenticated Users on Cloud

shiny
#1

Hello everybody,

I have developed fully functioning Shiny app and deployed it on my free account at shinyapps.io. Now I am looking to

  1. Scale it 300 (potentially 1000) daily unique users
  2. 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?

Shiny Server + AWS (EC2) ? AWS Pricing Calculator

Q1: Possible solutions and estimated related costs.
Q2: Time to setup/deploy proposed solution.

#2

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.

1 Like
#3

One user. RAM usage mostly (I assume) due to uploaded R.Data data.frame being 27.9Mb and dim(df) = 63059 148. Could be solved with database?

I estimate 50% of the users to spread across all US time zones. Rest of them across the globe.

What’s the latency standard?

Poor latency will have miniscule effect on good UX. They are coming for the information contained in the final data analysis reports.

#4

Could you load test your app with this.

1 Like
#5

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).

You can compare different hosting options here.

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).

#6

Here is the report:

What should I be looking at?

#7

What struck me looking at this (after opening the images in separate tabs to enlarge enough to make visible) is that major items are

  1. There is some serious latency that will lead to keybanging by impatient users that will increase load.
  2. Compute operations take a relatively long time, which suggests the logic may involve unnecessary looping or other opportunities exist for better performance
  3. 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.
#8

This topic was automatically closed 54 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.