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.
What do activity types measure?
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 table below illustrates the workload associated with various low-level server activities. These activities form the building blocks of more complex operations in your application.
Activity types are building blocks
The table below illustrates the workload units associated with each basic activity type. Basic activity types are the building blocks for your app's functionality. Your app's functionality is made up of multiple basic activity types and the total cost of a specific operation is the sum of all the underlying activity types required to execute it. For example, performing a database search has the base cost reflected in the table, but the total cost can vary depending on the complexity of the search and the amount of data to search through and return.
By understanding these basic activities and their associated costs, you can better optimize your application's performance and resource usage. 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.
| Activity | WU | Uses |
|---|---|---|
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 |
0.3 | Database | |
∟ of data returned from the database | 0.000003 | Database |
∟ returned from the database | 0.015 | Database |
a specific item | ||
∟ of data returned from the database | 0.000003 | |
∟ 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 thing deleted from the database | 0.1 | Database |
Each thing written to or modified in the database | 0.5 | Database |
Backend and API | ||
Each backend database trigger event | 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