the reactivity model that Shiny uses requires checking if inputs has changed. This checking is preformed in a very short time intervals, so a user has an impression that a change of an input triggers an event in the application. We know that this is only impression.
My question is: does this instant checking for changes in inputs may generate internet traffic, and in some cases some costs?
My question is rather theoretical, but I would like to understand the reactivity in details.
Thank You an all the best for Shiny programmers
This is a fantastic question. I don't know enough about the internals of Shiny to stay for certain, but I thought it used a more standard "callback" based reactivity paradigm (rather than continuous polling). I.e. when a value is changed, then it "pushes" through the dependency tree rather than waiting for the children to "poll" / "pull" the update.
That's how I think of it, at least Again, I do not know enough about the internals to say for sure what the actual implementation looks like. I will say for the poll-approach, you can do things like
invalidateLater(), but I do not know if that is super relevant to your question.
I will say that, regarding traffic, Shiny has been shown to scale well (linearly, like most production-capable web frameworks) to 10,000 concurrent users. For the demo, the app was hosted on RStudio Connect:
There are new tools for load testing if you are trying to prepare for a certain level of performance:
Joe also shared a talk at rstudio::conf about what some of the common issues with performance are. Spoiler: I/O and caching
Hope that helps! And maybe someone more knowledgeable of the internals will come here and enlighten us about the actual implementation of Shiny's reactivity!
This topic was automatically closed 21 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.