A brilliant application is unstable in many concurrent requests

Question

I built a quiz system using Shiny Server on Amazon web services. The system works reliably when I tested it on one or two devices at home. However, when I used it in a classroom with more than 10 students, the system broke down. Questions and widgets loaded correctly, but when students tried to present their answers (after 30-40 minutes, looking at them), the data was not processed correctly (the results are saved in the csv file so that I can see it).

I understand that there can be many reasons for this, but I would like to know if it could be that the Shiny server is simply not designed to handle many simultaneous requests. That would mean that I can just forget about using Shiny for my purposes and look elsewhere. For those interested in the system, here is the code:

https://github.com/witusj/CFA-2/tree/master/WK4

Many thanks!

Answer 1

What @FvD said. But besides that, remember that shinyapps.io , if you want someone else to be able to host your application in a scalable way, or Shiny Server Pro , if you want to return a Brilliant application with multiple R processes.

A brilliant server can certainly handle a lot of requests (we saw that one instance of Shiny Server gracefully handles up to a thousand simultaneous users) - and it had a lot of space for more, but, as described in @FvD, it all comes down to how much Well your R application scales.

One caveat here: there is a bit of difficulty to peek into an application like yours. If you write all your data in one. CSV file, then you cannot safely run multiple instances of the application at the same time (processes will overwrite each other). Instead, you might consider putting the results in a bunch of different CSV files that can later be combined, or you can use something like a relational database to really do it right. This issue is described in more detail here .

Answer 2

It depends on the complexity of your application and the server on which you host it. There is an explanation of one of their developers here , although there is no clear indication.

Since you have students that you can test on, you can get an estimate of how many users the application will be able to handle correctly, and use this number to set a limit on the number of people who can join. If you look at the manual , you will find a "Simple Scheduler" for this. To use the example from the manual, if you want to limit the number of connected students to 5, you must add simple_scheduler to your configuration:

 location / { # Define the scheduler to use for this location simple_scheduler 5; ... } 

Since you have more than 5 students, install multiple copies of the application in different places. You can expand this using the idea of ​​load balancing Huidong Tang or the implementation of this sjewo idea .