Understanding the workload calculation
Last updated
Last updated
In the Account and Pricing section of the Bubble documentation, we explore the specific activity types that controbute to workload. This includes a table of different activities, as well as their exact cost.
While this table gives an accurate image, it can still be difficult to extrapolate that information to real-life scenarios. In this article we'll go a bit deeper into the theory of how it's calculated, to make planning and designing your app and its user experience easier.
The first important point is one that we've repeated numerous times in the documentation: workload is a metric that measures the work that the Bubble server is doing to power your app. While you may have read that before, this sentence will make up the foundation of how we need to think about workload.
To get an understanding of why the values in the table don't necessarily represent what you see in the final logs, we'll use the theme park metaphor. Imagine the workload table values as entrance tickets to a theme park. While the ticket gets you into the park, each ride inside might have its own additional cost, which can vary depending on the details and specifics of that activity.
Just as some roller coasters might have a higher fee due to their popularity or thrill factor, certain operations in your Bubble app can be more resource-intensive based on how they're executed. In other words, the value in the table represents the starting cost of an operation – but the volume and complexity of that operation determines the final value.
Having established that metaphor, let's have a look at some examples to further illustrate the point:
This item in the table is easy to understand: for each item that you write to in the database (For example using the action), a cost of 0.5 workload is incurred. Now, let's return to the theme park metaphor: 0.5 is the price of the entrance ticket to the theme park called Make changes to a thing. Within that theme park, we may still have to pay for the rides inside.
Let's imagine that we are storing some statistical information in the database. We want to count all the registered users in our app, and save them on a data type called Statistic.
We've already paid our 0.5 for the entrance ticket (starting the Make changes to a thing action), now let's see what rides in the theme park we have to pay for. In the example above, we're asking the server to do three things:
Search for a Statistic thing and return the first result
Search for the User thing and return the count
Make changes to the field Number of users, using the result of step 2
So while our ticket allows us to enter the park, at the end of the day we can also look back at having paid for three different rides with varying costs. This is why, as we mentioned in the opening of this article, it's important to understand the total server load rather than just the cost of starting a process.
In the above example, you are not asking the server to do one thing, but three. The final load on the server also depends on the number of Users and Statistics in the database, and how much data they contain.
This point too is pretty easy to read: to perform an aggregate query means to take a list of data and make an aggregation such as a count or calculating an average. This is listed with a cost (entry ticket) of 0.2, but again we need to take every detail of the operation into account.
Starting the aggregation calculation has a cost of 0.2, but the data to be aggregated needs to come from a . In many cases, this will be the result of a dynamic expression using the data source.
What this means, is that this operation needs to be added to the total calculation. According to the activity type chart, a database search has a starting cost of 0.3. The complexity of that search and the volume of data can add to the cost of it.
Finally, sending data from the server also has a cost of 0.000003 per character of data transmitted. Since we are returning a number in this case, that cost would be very low, but still a part of the full picture. Let's sum up what we are adding to workload in this example:
A Do a search for query (start cost: 0.3)
An aggregation of the results of that data (start cost 0.2)
Sending the data to the user's device (cost 0.000003 per character)
Again, it's important to understand that the total cost can increase, depending on the complexity of an operation. If the Do a search for includes advanced filters performer server-side, then that will be calculated into the total. Again, it may seem like we are performing one action, but technically, Bubble's server is performing the three listed above.
Having looked at these two examples, the workload metric may feel convoluted to predict and understand, but let's re-visit its purpose: to give a realistic and fair calculation of the work the server has to do to power your app. It may feel overwhelming to be expected to calculate the minutiae details in the examples we provided above, but that's not their intention: most operations in Bubble (the two examples included) are very low-cost to execute and there's no need to analyze, understand and predict every single operation down to the last decimal place.
Rather, it's about getting a basic understanding of how the totality of the workload is calculated. For example, if you set up a Make changes to a thing that includes an expression with a highly complex Do a search for using advanced filters, it's helpful to know that this is a part of the total metric calculation. This knowledge helps you make informed decisions, while the low cost of each individual operation also means there's no need to obsessively prioritize workload above everything else. Mostly, the cost of a single operation only becomes visible whenever that operation is repeated frequently, such as on page load or when working with bulk data. We'll get back to both points in this article series.
With this information in mind as you plan and build your app, you can take into account how different activity types are combined inside of a single action or expression to make up a total. For example, knowing that an complex search as part of an action is a fairly heavy database operation, you can take steps to find alternative solutions that consume less workload while retaining the same functionality.
We go deeper into how to plan for workload in the article below:
Article: Planning for workload
The number one tool that you have at your disposal to understand, and optimize for, workload in your app, is the workload metrics dashboard. This allows you to drill down into the different activity types and explore directly in the editor what parts of your app are consuming the most. Reports, of course, come with some caveats:
They report on what has already taken place: they don't predict
Substantial workload consumption often becomes visible when your app has a large volume of users and the operations start to scale
Nevertheless, monitoring the reports provides valuable insights into how various design decisions impact the workload metric. As you progress with Bubble and see an increasing number of live users interacting with your app's features, you'll naturally develop an intuition for refining current functionalities and strategically planning future projects for optimal performance.
We cover how to use the app metrics to analyze workload in the article below:
Article: Using App Metrics
Workload is all about server work; in other words, things happening client-side don't cost workload at all, unless it involves some work from the server. Let's illustrate with an example:
Custom states are saved on the user's device, and as such do not involve the server. Thus, the action to set a custom state in itself does not incur any WU. Let's say you want to set a custom state of type text and assign it the value "Example".
In this case, the workload consumption would be 0.
In our second example, we want to use a custom state with a custom data type that we need to fetch from the database. In this case, the Set state of a custom element action would still be free, but searching for the data would incur a cost, in two steps:
Using Do a search for incurs a starting price (the "entry ticket")
The complexity of the search and volume of data is calculated into the total
The data returned from the server incurs a cost per character returned
As we can see in this example, since the client-side action (setting the custom state) requires an additional server-side action (searching for and returning data), it will incur a small WU cost.
The Go to page can be used to assign URL parameters to the URL and navigate a single-page application. As long as you are staying on the same page and not loading a different page, this too is a purely client-side action and does not incur any WU consumption.
(keep in mind that workflows that execute on page load might still be repeated and consume WU. We cover this in-depth in the article below).
Article: Page load and workload
In this example, we're using the Go to page action to change the Page thing. In this case, even though we are still on the same page, Bubble will need to fetch the data for the new Page thing and spend some WU on it. How much depends on how you instruct Bubble to find the data. For example, if you use Do a search for you may be consuming a bit more WU than if you reference it directly, such as Current user's Active project.
If you are using the Go to page action to navigate to a different page, you're again asking the server for some information:
Loading the page itself (generating the code and sending it to the browser)
Loading the data needed for the page (searches, repeating groups, aggregated numbers and other dynamic expressions)
Running workflows set to execute on page load
Again, page load is covered more in-depth in the article below:
Article: Page load and workload
