Scaling Your App

The are two ways to scale your app:

• Horizontally, by increasing the number of replicas for your app processes.
• Vertically, by adding workers to your gunicorn web process.

Scaling with Replicas

Scaling your app horizontally by adding replicas is more resource-intensive, but has many advantages.

About App Replicas

You can think of a replica as a copy of your Dash app. Increasing the number of replicas for your app provides:

• Increased availability. When multiple replicas are available to be served to your app users, your app’s availability increases.
• Increased performance. With multiple replicas of your app’s web process, callbacks are run in parallel, meaning your app runs faster. For example, if you scale an app that has the following four callbacks from one replica to four replicas, the callbacks will complete four times faster:
  ```python
  app.layout = html.Div([
  html.Div(id=’btn’, children=’Run’),
  dcc.Graph(id=’graph-1’),
  dcc.Graph(id=’graph-2’),
  dcc.Graph(id=’graph-3’),
  dcc.Graph(id=’graph-4’),
  ])

@callback(Output(‘graph-1’, ‘figure’), Input(‘btn’, ‘n_clicks’))
def update(_):
time.sleep(2) # This simulates a long-running callback
now = datetime.datetime.now()
return px.bar(x=[now - datetime.timedelta(minutes=1), now], y=[random.random(), random.random()])

@callback(Output(‘graph-2’, ‘figure’), Input(‘btn’, ‘n_clicks’))
def update(_):
time.sleep(2) # This simulates a long-running callback
now = datetime.datetime.now()
return px.bar(x=[now - datetime.timedelta(minutes=1), now], y=[random.random(), random.random()])

@callback(Output(‘graph-3’, ‘figure’), Input(‘btn’, ‘n_clicks’))
def update(_):
time.sleep(2) # This simulates a long-running callback
now = datetime.datetime.now()
return px.bar(x=[now - datetime.timedelta(minutes=1), now], y=[random.random(), random.random()])

@callback(Output(‘graph-4’, ‘figure’), Input(‘btn’, ‘n_clicks’))
def update(_):
time.sleep(2) # This simulates a long-running callback
now = datetime.datetime.now()
return px.bar(x=[now - datetime.timedelta(minutes=1), now], y=[random.random(), random.random()])
```

Configuring the Number of Replicas

You can manage replicas in the Scale tab of your App Info.

By default, each process type defined in your Procfile runs as one replica. For example, with the following Procfile, you’ll see a single Web process card in the Scale tab:

web: gunicorn index:server --workers 2

Each process can be scaled up to a maximum of 10 replicas. Each replica that you add increases your app’s overall memory usage. See Memory Usage Considerations for more information.

To change the number of replicas for an app process:

1. Go to your App Info at https://<your-dash-enterprise-server>/apps/<your-app-name>.
2. Go to the Scale tab.
3. Find the process that you want to scale, and then select Edit Resources.
4. Update the replica count.
5. Select Save.

Scaling with Gunicorn

You can vertically scale your app by increasing the number of workers in the gunicorn web process defined in your Procfile. To do this, modify the value for the --workers flag, and then redeploy your app.

web: gunicorn app:server --workers 4

We recommend between 2 and 4 workers for most Dash apps.

See the App Structure page for more details on Procfile.

Memory Usage Considerations

By default, each replica and workspace has a memory usage limit of 8 GiB, and administrators can configure this default.

To monitor your app’s overall memory usage, use the Memory Usage information in the Scale tab. This information displays the current memory usage for your app’s combined processes and workspace. The maximum memory represents the sum of the memory limits for your app’s replicas and workspace. For example, with the default 8 GiB memory limit, an app with one web process that is scaled to two replicas and one workspace has an overall maximum memory limit of 24 GiB. Memory usage for managed Redis and Postgres databases is not shown.

<img>

If your app reaches its memory limit, your app is stopped. You have two options:

• Try to reduce memory usage. Some strategies include:
• Using the --preload flag in your Procfile. For example:
  web: gunicorn app:server --workers 4 --preload

Do not use the --preload flag if you are using shared database connection pools (see Database Connections). For more information on preloading, refer to the Gunicorn docs.
* Reducing the amount of workers defined in your Procfile.
* Using a file type for your dataset that supports memory mapping, like Arrow, and reading it with libraries like Vaex.
* Performing data queries and aggregations within the query on a database layer instead of in memory with Python. * Ask your administrator to increase your app’s memory limit. If they set a custom memory limit, your app is restarted. If your app uses the default memory limit and your administrator opts to instead increase this default, restart your app using the Start <img> button in the Overview tab.