I have a memory-intensive Shiny app deployed on shinyapps.io's Basic tier. After trying to configure settings to reserve one instance for each user, I now have issues where the second user who connects receives a 503 error. What I expect is that they'll be able to connect to the app just like the first user.
Does anyone have any guidance on how I should be structuring the shinyapps.io backend to avoid this error and ensure each of my users successfully connects to their own instance?
For background:
The image below is what the second user sees. Refreshing does not appear to solve the issue, nor does connecting again in a separate incognito window (other users mentioned a cache issue). Spacing out the connections by a minute or two also does not fix the issue.
I'm confused because:
To reserve one worker and one instance for each user, max workers and max connections are both set to 1.
I've set the app have a 10 instance Start Count. This is unneccessary at most times, but I'm surprised this is not solving the issue.
I also set the instance load factor to an especially low 1% value, hoping that it would prevent the next user from receiving the error.
The issues are similar to the post here, where a few users reported 503 errors. In their cases, the 503 errors happened inconsistently; one user also had them appear on startup, but their was no particular response to their issue. Because the thread is now locked, I've started this new post.
Well, shinyapps.io support got back to me, so I can share their answer here. The trick is that additional instances will not be setup to turn on by default, even if you play with the settings described above; you need to create instances in advance as shown on the image below:
By default, an application is capped at a single instance available, even with the tiered plans that allow additional instances. To add additional instances to an app, you will also need to add instances to the Instances list on the application overview page, seen below. Instances may be increased up to the max instances available on your plan.
This mechanism is set up to prevent applications from consuming more active hours unintentionally. Once you add additional instances, this application should start to allow additional user connections and spin up the additional instances as needed.
As an additional note, Start Count specifies how many instances will start when the app starts; the instances in the Application Overview are the pool of instances that can be started. However, if these instances aren't being used right as the app starts, they will go back to an idle/stopped state until something triggers them to turn back on.
