MyNixOS website logo
Description

Load Test Shiny Applications.

Assesses the number of concurrent users 'shiny' applications are capable of supporting, and for directing application changes in order to support a higher number of users. Provides facilities for recording 'shiny' application sessions, playing recorded sessions against a target server at load, and analyzing the resulting metrics.

Load Testing Shiny Applications

R-CMD-check

The shinyloadtest package and the accompanying shinycannon command line tool make it possible to load test deployed Shiny apps. Load testing helps developers and administrators estimate how many users their application can support. If an application requires tuning, load testing and load test result analysis can be used to identify performance bottlenecks and to guide changes to infrastructure, configuration, or code.

Scientific load testing helps put to rest the common misconception that “Shiny doesn’t scale”. As rstudio::conf(2018) Sean Lopp presented on Scaling Shiny which shows how to to horizontally scale an app to handle tens of thousands of users.

Installation

To perform a load test you’ll need two pieces of software:

  • shinyloadtest is an R package used to generate recordings and analyze results. You should install it on your development machine with install.packages("shinyloadtest").
  • shinycannon is a command-line used to replay recordings in parallel. You can install it on your development machine for testing, but for best results we recommend installing it on a server, and preferably not the one the application under test is also on. See installation instructions for operating specific install instructions..

Quick Start

The process for load testing a Shiny application consists of three steps:

  1. Record a typical user session for the app.
  2. Replay the session in parallel, simulating many simultaneous users accessing the app.
  3. Analyze the results of the load test and determine if the app performed well enough.

Rinse and repeat as necessary. Each step is described below.

Step 1: Recording

Record a session using shinyloadtest::record_session(), which takes the URL of the deployed application as an argument:

shinyloadtest::record_session("https://shinyapp.example.com/")

Running the function will open a browser displaying the app. Once open, interact with the application as a typical user might then close the browser. After closing the app, a file (recording.log by default) will be created that contains a recording of the session. This recording will serve as the basis for the load test.

If your application requires authentication, consult the authentication article. Also be aware that certain Shiny features are not compatible with shinyloadtest.

Step 2: Run the Load Test

With the recording in hand, we’re ready to run the load test. The actual test is conducted outside of R using the shinycannon command-line tool. You can run it using your system’s terminal or console program, or you can run it from the RStudio IDE’s terminal tab. A typical run looks like this:

shinycannon recording.log https://shinyapp.example.com/ --workers 5 --loaded-duration-minutes 2 --output-dir run1

(On Windows, you will need to replace “shinycannon” with java -jar shinycannon-VERSION.jar.)

See the shinycannon article for details.

Step 3: Analyze the Results

Now we can analyse our results by reading the data into shinyloadtest::load_runs() and create a report with shinyloadtest_report():

df <- shinyloadtest::load_runs("run1")
shinyloadtest::shinyloadtest_report(df, "run1.html")

This self contained html report will be opened in your browser for inspection. For further analysis explanation, please visit Analysing load test logs.

Analysis Example
Metadata

Version

1.2.0

License

Unknown

Platforms (77)

    Darwin
    FreeBSD
    Genode
    GHCJS
    Linux
    MMIXware
    NetBSD
    none
    OpenBSD
    Redox
    Solaris
    WASI
    Windows
Show all
  • aarch64-darwin
  • aarch64-freebsd
  • aarch64-genode
  • aarch64-linux
  • aarch64-netbsd
  • aarch64-none
  • aarch64-windows
  • aarch64_be-none
  • arm-none
  • armv5tel-linux
  • armv6l-linux
  • armv6l-netbsd
  • armv6l-none
  • armv7a-darwin
  • armv7a-linux
  • armv7a-netbsd
  • armv7l-linux
  • armv7l-netbsd
  • avr-none
  • i686-cygwin
  • i686-darwin
  • i686-freebsd
  • i686-genode
  • i686-linux
  • i686-netbsd
  • i686-none
  • i686-openbsd
  • i686-windows
  • javascript-ghcjs
  • loongarch64-linux
  • m68k-linux
  • m68k-netbsd
  • m68k-none
  • microblaze-linux
  • microblaze-none
  • microblazeel-linux
  • microblazeel-none
  • mips-linux
  • mips-none
  • mips64-linux
  • mips64-none
  • mips64el-linux
  • mipsel-linux
  • mipsel-netbsd
  • mmix-mmixware
  • msp430-none
  • or1k-none
  • powerpc-netbsd
  • powerpc-none
  • powerpc64-linux
  • powerpc64le-linux
  • powerpcle-none
  • riscv32-linux
  • riscv32-netbsd
  • riscv32-none
  • riscv64-linux
  • riscv64-netbsd
  • riscv64-none
  • rx-none
  • s390-linux
  • s390-none
  • s390x-linux
  • s390x-none
  • vc4-none
  • wasm32-wasi
  • wasm64-wasi
  • x86_64-cygwin
  • x86_64-darwin
  • x86_64-freebsd
  • x86_64-genode
  • x86_64-linux
  • x86_64-netbsd
  • x86_64-none
  • x86_64-openbsd
  • x86_64-redox
  • x86_64-solaris
  • x86_64-windows