Skip to main content

​
Domino applications

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 file that you have selected, at which point your application is 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.

​
Flask and Dash (Python)

By default, Flask and Dash 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 file. See Gunicorn commands for details. You can change:
to
This starts serving the Flask application on four processes. Note that port selection is flexible and port 8888 is no longer required. The performance and scalability of your App 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 uses 100 MB 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 sixth user attempting to run the command would cause the App’s performance to suffer. There would be RAM available, but not enough CPU cycles.

​
Shiny (R)

Like Python Apps, your Shiny Apps’ performance depends 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. See Make Shiny fast by doing as little work as possible.

Related topics

Understand App usageApp Structure and LifecycleOn-demand SparkMonitor model endpoints