Dash Enterprise Single Server

To avoid any issues that may arise as a result of running multiple applications on the same server, we strongly recommend using a dedicated server or VM to run Dash Enterprise.

We do not recommend enabling SELinux on the server.

You must have root access to the server you’re using.

The server requires Internet access to download installation files (proxy servers are supported). If Internet access is not an option, see Fully Offline Installation.

Ensure the Docker data directory (/var/lib/docker has enough space allocated to it, at least 100 GB.

Certain Docker storage drivers are not supported as they are either deprecated or not intended to be used in production environments. This includes the zfs, btrfs, and devicemapper (in loopback mode) storage drivers. If you are uncertain whether your Docker storage driver is fully supported, please contact Dash Enterprise support.

Memory and CPU needs will increase as you deploy more Dash applications and workspaces, so plan to monitor and scale up your server resources correspondingly. We recommend configuring an external memory and CPU monitor (AWS Cloudwatch, Google Cloud metrics, or Azure Monitor) and setting an alert for when memory usage reaches 70%. This should provide adequate warning to plan an upgrade or communicate with your user base to rescale their applications. If you find yourself rescaling frequently, consider Dash Enterprise Kubernetes to enable autoscaling functionality in your cluster.

The recommendations in the below table are a lower bound of memory and CPU requirements. Your users may require much more memory or CPU depending on the types of applications that they build and viewership. See “Behind the Recommendations” below for an explanation of how to determine resource allocation.

Capacity Planning Table

The following table serves as a guide for your capacity planning, with suggested machine types on AWS and Azure

	Minimum CPU	Minimum Memory	AWS	Azure	Minimum Disk Space
5 Apps & Workspaces	14	29GB	c6g.4xlarge	Standard_F16s_v2	479GiB
10 Apps & Workspaces	24	54GB	c6g.8xlarge	Standard_F32s_v2	917GiB
25 Apps & Workspaces	54	128GB	c6g.16xlarge	Standard_F64s_v2	2229GiB
50 Apps & Workspaces	104	252GB			4417GiB
> 50 Apps & Workspaces	We recommend running apps across multiple servers with Dash Enterprise Kubernetes

Behind the recommendations

Memory usage

Dash apps, workspaces, and job queues consume memory while idle and awaiting requests. Depending on the app’s code, the memory may or may not be substantially larger than these baseline requirements.

Dash Enterprise core services require 4 GB RAM to run without any user-created Dash apps, workspaces, or job queues.

For each Dash app deployed, standard barebones memory requirements are:

1. Dash app snapshotting job queue containers with minimal data running 4 processes: 0.75 GB

   1. “Minimal data” example: a dataframe shaped with 10,000 rows and 3 columns loaded into memory, with about a dozen pandas operations applied on it

   2. Memory usage is lower if data isn’t loaded into memory and correspondingly higher the more data is loaded into memory

   3. Each app is scaled using 4 preloaded gunicorn workers that share memory, rather than being scaled with containers

2. Job queue container (for Dash Snapshot Engine and updating data in the background): 0.75 GB

3. Workspace container with minimal data: 1.5GB

4. Redis container with minimal data: 200MB

   1. See 1.1 for “minimal data” example

   2. A Redis database’s memory footprint varies widely depending on how it’s used (caching, shared session store, job queue message interchange)

5. Postgres container without any data: negligible (roughly 11MB)

6. Recommended memory expansion factor: 1.5x

To estimate how much RAM to provision your server with, you can use the below formula, assuming your apps will use a “minimal data” profile as described above in 1.1. When counting the number of apps you expect to need to host, consider any app’s associated workspace and job queue containers as part of the app for your count; if you have one app with a workspace and a job queue, count it as one app for your estimate:

Server memory = 4GB + (number of apps * 3.3GB per barebones app * 1.5 expansion factor)

As an example, five Dash apps, each with snapshots enabled and a workspace, require a server with:

Server memory = 4GB + (5 apps * 3.3GB per barebones app* 1.5 expansion factor) = 28.75GB

For a more accurate prediction, consider measuring your application’s actual resource consumption and using that information in your calculation in place of the barebones estimate.

CPU usage

Dash apps, workspaces, and job queues do not consume CPU while idle and awaiting requests.

The Dash App Manager and all Dash apps share the same set of CPU resources, so you will need to consider the following when allocating CPUs to your server:

• The maximum number of viewers and users expected to interact with apps or the Dash App Manager at any given moment

• How long the deployed apps’ computations take

Because this is difficult to predict, we recommend implementing a CPU usage monitor and scaling up when CPU use reaches 75% of maximum.

As an example, if your apps are being distributed across to 100 people every morning at 9 a.m., this may require anywhere between one to 10 CPUs. Here are different scenarios with different CPU counts:

• Higher-bound example using 10 CPUs: all 100 people attempt to load the webpage at the exact same time

  • Each backend request to load the web page takes about three seconds

  • The server times out after 30 seconds, meaning the requests must be fulfilled within 10 three-second batches

  • Processing 100 people’s requests in 10 batches needs 10 CPUs

  • Some users will wait 27 seconds before seeing the page load

• Lower-bound example using one CPU: all 100 people attempt to load the webpage across five minutes from 9 a.m. to 9:05 a.m.

  • Five minutes equals 300 seconds, which means 100 three-second requests are queued

  • A single CPU can process one request every three seconds

  • All 100 users will have had their web requests complete after five minutes.

Your actual Dash Enterprise use will probably be a mix of the above scenarios. As a lower bound for CPU count, consider:

• 4 CPUs for Dash Enterprise core services

• 1 CPU per Dash app

  • Since CPU is shared, higher-traffic apps will use as many idle CPUs as are available

• 1 CPU per workspace

If all of your apps and workspaces are in high demand at the same time, you will need to scale your CPU allocation up. That said, the minimum CPU count is 4, but we recommend 8 in production.

Disk Space

Three paths are used for a Dash Enterprise server, /plotly, /var/lib/docker and /var/lib/replicated, but only the first two grow in size as the Dash Enterprise server sees more usage:

• /plotly: The “Plotly directory”. By default it is /plotly but that is configurable. This is where all the server data is saved, including the PostgreSQL database data, app data, app settings, and more. This directory should be backed up.

• /var/lib/docker: This is the default Docker directory. This is where Docker saves all its data and files. For example the docker images, volumes, volume metadata, etc. A Dash Enterprise server admin typically doesn't need to understand and troubleshoot anything in this directory to manage Dash Enterprise, and it doesn't need to be backed up for upgrades or disaster recovery. However, it's important to note that this directory grows as more apps are deployed and workspaces are created.

These two directories could live either on two separate disk/partitions or on the same disk/partition. If you have them both on the same disk or partition, you can simply add up the numbers in the formula below.

Formula

The following benchmarks assume the following about the example application:

• The requirements.txt packages used: plotly, dash and gunicorn

• Installed python packages: ~328MB

• App code: ~21MB

Disk space used:

• /plotly: 1GB + (Number of apps 0.5GB) 5

• /var/lib/docker: 40GB + (Number of apps 17GB) 5

• /var/lib/replicated: 0.5GB

Where:

• 1GB - Base-level disk space required by the install

• 0.5GB - The disk space used by an app that installs plotly, dash, and gunicorn. This may increase if apps commit large files or install large packages.

• 40GB - Base-level disk space required by Docker

• 17GB - Disk space created by Docker images of the App and Workspace. This may increase if apps commit large files or install large packages.

• 5 - “Wiggle Room” Factor - Multiplier to provide extra disk space in case of unexpected usage. We use a high factor as disk space is cheap.

• 0.5GB - Base-level disk space used by Dash Enterprise’s Replicated dependency. Does not grow significantly during usage.

If /plotly and /var/lib/docker are on the same disk/partition, the disk space recommendation formula would be the sum of both:

(1GB + (Number of apps * 0.5GB) * 5) + (40GB + (Number of apps * 17GB) * 5) + 0.5GB

Or...

(1GB + (Number of apps * 2.5)) + (40GB + (Number of apps * 85)) + 0.5GB