Activity types

This section covers how different activity types contribute to your app's total workload

We track various activity types, each of which contributes to the overall workload. We calculate the total work that occurs during each month, and reset the count at the beginning of each new month. Since every app is unique, this approach ensures a use-case agnostic way that lets you scale your app based on actual consumption.

Each of the activity types below contribute to your app’s total monthly workload. You can gain deeper insight into some of these metrics by exploring your app's workload charts and identify the areas of your app that are doing the most work and take steps to optimize their performance.

Activity types

Server processing versus client-side processing

Workload incurs for work that happens on the Bubble server. This is often, but not exclusively, related to database operations. As such, operations that happen client-side (on the user's device) without having to communicate with the server, do not incur workload.

Keep in mind that a client-side action (such as show/hide an element) happens on the client, but may still incur a cost if you involve the server in another way. For example, if the show/hide action contains a condition that checks something on the server, that dynamic expression will incur a cost. Likewise, the Go to page action , but it may result in loading a new page, which does incur a WU cost.

If you are looking into optimizing your app for workload, it's important to understand the difference between server-side and client-side operations.

  • Article: Client-side and server-side processing This article covers the difference between the work that happens on the server, and what happens on the user's device (the client).

  • Article: The frontend and backend This article covers the difference in operations that are triggered by your users from the frontend (your app), and operations that are triggered and performed 100% on the server (such as inbound API calls).

The below table represents the cost of the raw ingredients for an action. In other words, the ultimate cost of an action can be different than the table indicates, depending on what that activity does. For example, performing a database search has the base cost reflected in the table, but that cost can vary depending on the complexity of the search and the amount of data to search through and return.

As a result, if the actual workload consumption doesn't match your expectations, we recommend using your app metrics to isolate the activities that consume the most workload and look at ways to make it more efficient.

ActivityWUUses

Page load

0.15

Frontend

Plugins

Each call to a server-side plugin action

0.2

Plugin

Each millisecond spent executing a server-side plugin action

0.0005

Plugin

Each row retrieved by our SQL Connector plugin

0.015

SQLPlugin

Each call made by our SQL Connector plugin

0.1

SQLPlugin

Performing a database search

0.3

Database

∟ Each character of data returned from the database

0.000003

Database

∟ Each result returned from the database

0.015

Database

Lookup a specific item

∟ Each character of data returned from the database

0.000003

∟ Each result returned from the database

0.015

Each call to watch a search for real-time updates

0.005

Database

Performing an aggregate query in the database

0.2

Database

Performing a "group by" query in the database

0.3

Database

Each item deleted from the database

0.1

Database

Each item written to or modified in the database

0.5

Database

Backend and API

Each backend data trigger workflow initiated

0.05

Backend

Each inbound call to an app's Data and Workflow API

0.01

APIBackend

Bytes sent to or from an app via inbound or outbound API

0.000003

API

Each outbound API call made to an external API

0.1

API

Running a server-side workflow action

0.6

Backend

Adding a new item to the API workflow scheduler

0.1

API

Checking specific workload units consumed in the logs

Using the Server logs tab, you can check the workload charged for each action, as well as the total for each workflow.

Drilling down using the App metrics dashboard

In many cases, workload consumption can be isolated to a select few of your app’s processes that are either workload-intensive or triggered frequently. To help you identify what pages and activities in your app are consuming the most workload, you can use the App Metrics dashboard to get an overview.

There, you can see the total aggregated workload usage for the last 30 days, broken down by Development and Live consumption. Both Development and Live contribute to your total usage.

To learn more about how to use app metrics to drill down into your app’s workload activities, check out the article below or try our interactive walk-through:

Article: Using App metrics Interactive walk-through: Exploring Workload Usage

In the same dashboard, you can also see a pie chart visualization of which activities contributed the most to workflow usage in the selected period. You can use the bar chart to select the time period to include in the pie chart visualization. By clicking on a sector in the pie chart, you can drill down to see where in your app this is occurring, down to individual pages, workflows, elements and expressions.

Last updated