Update on workload resources and tooling

Hi everyone,

I’m Laura Oppenheimer, a group product manager here at Bubble and I lead our efforts on monetization. This quarter, we’ve been improving our workload tooling, education, and documentation to help you build with confidence. Whether you’ve been on new pricing for months or preparing to migrate by October 1, we hope these updates will be useful tools for you and your app.

Now available:

We’re excited to share more resources that can help you better understand workload tools and how to optimize your app for efficiency:

  • Out today: For our audio/visual learners out there, we collaborated with @Gregory John to create Bubble Workload Management, a 3-part video series on YouTube. In this course, you’ll learn how workload works, ways to track it, and best practices for optimizing for workload efficiency.
  • ICYMI: We partnered with @Petter Amlie to refresh the Workload section in the Bubble Manual with new and updated articles, including how to use app metrics and an optimization framework, checklist, and case studies with actionable tips. Thanks for the continued feedback on them!

Relatedly, it’s awesome to see community members like @Jici sharing how they optimized their apps for efficiency. They helped a user portal app go from consuming 850,000 WU to 150,000 WU a month - as well as reducing a 24 hour process to only 2 hours. Every app is unique, but excited to hear more examples of what’s worked for you.

Sneak peeks: App metrics updates

We’re making two updates to the app metrics page: Improvements to the pie chart, and new data on workload consumed over time. Special thanks to @brian9 and @boston85719 for the feedback and eyes on these two projects!

Pie chart improvements

Currently, you can see the total number of WU consumed by each activity type, and its percent of overall WU consumption. Next month, you will also see how many times a given activity has occurred and if it’s worth digging into further. These are the activity types that you’ll have visibility into: workflow runs, pageloads, searches, API calls, file uploads, autobinds and imports/exports. This will make it easier for you to optimize your app’s workload consumption.

For example, today if you hover over a wedge on the pie chart, you can see that there were 1,000 workload units consumed. But you can’t see if it was a single workflow consuming 1,000 workload units or 1,000 workflows consuming 1,000 workload units. One of these you may want to look into (it’s the single workflow consuming 1,000 WU!), while the other may not be worth your time. The new update will offer this visibility.

Look for this rolling out in the first week of September — along with more UI improvements to the pie chart and app metrics page. (Those with eagle eyes may have already spotted an update to the colors in the pie chart.)

Pie chart final

Data on workload consumption over time

Currently, the app metrics page shows two charts: a pie chart showing what is consuming workload and a bar chart showing workload usage over the past 30 days. Next month, we’re shipping a new chart that will let you view what activities are consuming workload and how your consumption is changing over time.

(Some inspiration for where we’re headed here :point_down:)

When you’re looking to optimize your application, knowing what to focus on is the first step. This data will help identify the biggest things that have changed that might need your attention, so you can optimize your application — and your time.

As always, we look forward to hearing your feedback.

Laura

31 Likes

Awesome to see these new things :smiley:

Great update!

Just like the average WU per activity type stats, hoping to see stuff like ‘average WU per workflow run’ for each workflow in any future revamp of logs!

6 Likes

Having averages will really help in nailing down optimisations!

Had a look into the documentation for WU and this struck out:

Identical searches on the same page are only queried once, but queries in workflows are performed each time the workflow is executed. Consider using search results that have already been loaded when possible.

I had a feeling this was a thing.

2 Likes

Some great stuff in here!

I’d also love if it was possible to get the logs to be closer to real-time than they currently are (right now I run a test on Dev, and wait a full 3 minutes for it to show up on this log):

1 Like

any plans to get rid of the Other section on the pie chart? kind of hard to optimize when 20% of our WU spend can’t even be broken down

1 Like

I would love for Bubble to explain this in a bit more detail actually @laura.oppenheimer

Breaking it down:

  1. Searches of a datatype with the same constraints in elements will ping the database once
  2. Every Search of a datatype with the same constraints in a workflow will always ping the database. This includes Searches in conditions in a workflow.

If a Make changes to a thing has a condition, which uses a search that is used in the make changes action itself too, will we be charged for search twice?

Generally, Bubble doesn’t perform a search more than once, as longs as they are identical. Note that this applies to elements, while Do a search for performed in a workflow will be repeated each time that condition or action is executed.

You can find more information here.

Thanks.

So if in the same action step in a backend workflow, you had the same “Search of” (with the same constraints) more than once, would each of “Search of” be hitting the database?

From the documentation it’s safe to assume that is true.

Not sure if this is the best thread for this question, but today is the last day of the month and I was reviewing my WU and it appears there is a discrepancy between the App Metrics section and the Settings/App Plan section. I was expecting them to be the same, but maybe not?

The only strange thing here that could be the cause of the discrepancy is the App Metrics has the From date from August 1st at 6PM, which I am not sure if that is 6PM Eastern time or which time zone that is in? It appears that no matter what time of the day I check the App Metrics, it always defaults to this 6PM time. FYI, my browser time zone is Mountain and I also submitted a ticket on this.

In response to @maw :

We looked into this case, and we believe the information is accurate and the difference you’re seeing is due to time zones. (There’s some joke in the coding world about how time zones are just the worst)

In general, if you see a specific time, like “6:00pm”, in the editor, that’s in your local time. If you see a date without a time, that’s based on UTC time.

3 Likes

Chiming in to this thread to share that the pie chart improvements referenced in the original post are now live!

2 Likes

Would be great if you could have these two screens use the same time zone instead of two different time zones, it is a little confusing for us users to see discrepancies like this. Especially when we need to know when our new cycle of allowed WU officially starts?

@allenyang which time zone does my WU start over on the 1st of each month? Is it the first minute of the 1st day of my time zone or UTC or New York?? Sorry if this is stated somewhere else, but figured you would be able to quickly provide this information that I think others would like to know as well.

1 Like

Fair piece of feedback - though we’ll have to be careful about it because there are timestamps elsewhere in the product that don’t make as much sense to be in UTC.

The workload overage billing calculation happens at midnight UTC at the turn of each calendar month.

1 Like

The biggest change we need right now for workload tooling is to see the number of workflows per each section on the pie chart.

It’s very hard to optimize for something just by seeing the cumulative % share.

Being able to divide the total WU by the # of workflows would be amazing. That way we could actually drill down into the workflow itself and see how changing the actions/conditions affects WU.

This was added in this feature announcement.

4 Likes

Might start reading OPs from now on.

They might be working on a way to let us see what a particular user has used as well… :man_shrugging: :thinking: :wink:

1 Like