Launching an App in Domino works the same
as any other Domino run. Domino assigns hosting of your App to an executor machine in the
hardware tier
your App is
configured to use. That executor then retrieves the default Domino environment configured for your project, and creates a container based on that
image. Domino then loads your project files onto the machine and
executes the app.sh file that you have authored and placed in the
project root, at which point your application will be running in its
container.
Depending on which hardware tier you select, the container running your application may share a host machine with other containers or run on a dedicated host. Your selection of hardware tier allows you to specify available memory and CPU. However, Domino Apps do not automatically scale horizontally to multiple hosts. Your App can scale vertically to use all available resources on the executor host machine by correctly configuring the underlying application.
The following sections describe configuring web applications to optimize scalability and performance for several popular frameworks.
By default, Flask and Dash will run single-threaded on a single process. The authors of Flask do not recommend this configuration if you are going to serve more than 10 users concurrently, or for any externally consumed applications. The Flask documentation provides many ways to serve the application in a more scalable way.
For example, you can serve a Flask application through
gunicorn. To do this in Domino, change the
project’s app.sh file from:
python app.py
to
gunicorn -w 4 -b 0.0.0.0:8888 myproject:app
This will start serving the Flask application on 4 processes.
The performance and scalability of your App will depend on the compute demands of your application, and the compute resources available on the host machine. If there is a command in your application that will use 100MB RAM and 20% of a standard VM CPU, then an executor host machine with 1 core and 1 GB RAM could handle 5 concurrent users running that command without suffering reduced performance. A 6th user attempting to run the command would cause the App’s performance to suffer. There would be RAM available, but not enough CPU cycles.
Like Python Apps, your Shiny Apps' performance will depend on design of the underlying application. While multiple users can view Shiny applications in independent sessions, R is a single process language. This means that multiple users can view and interact with the App in their own isolated session, but only one can do any processing at a time regardless of the memory or CPU of the machine.
Shiny Apps typically cannot scale to more than a handful of concurrent users.