The following guidelines apply to all Domino apps, regardless of framework:
-
Apps run until you explicitly stop them. If your app isn’t used anymore, stop it to minimize your compute spend.
-
Unlike a job or a workspace, Domino apps never commit (or sync) file changes from the local disk to the Domino project’s file store. To persist data, your app’s logic must write it to an external data source.
-
The performance of your app depends on the design of the application.
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.
See Gunicorn commands for details.
You can change:
export LC_ALL=C.UTF-8 export LANG=C.UTF-8 export FLASK_APP=app-flask.py export FLASK_DEBUG=1 python -m flask run --host=0.0.0.0 --port=8888
to
gunicorn -w 4 -b 0.0.0.0:8888 app-flask:app
This will start serving the Flask application on four 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.