Submit your WORKLOAD questions!

Tips
1

Hey everyone,

For those that don’t know, I’m the guy working behind the scenes on the Bubble User Manual. We’re currently working on one of the most requested subjects: more in-depth guides on the workload metric.

As such, I’m trying to get an understanding of the most widely asked questions and areas where you want more detailed documentation. Please keep in mind that:

  • the questions we’re looking for are the ones that can improve the documentation, so this is not the thread for questions about future development of different tools, reports and the metric itself. (For that, you may be interested in this thread instead).
  • Focus on questions that are relevant to how to optimize for workload
  • If you have had great success optimizing in your own app, feel free to share that too

I appreciate the input! Let’s join forces and craft some stellar documentation on this :rocket:

5 Likes
2

I have many questions actually. Here is a list of them. Please excuse them being written in rough manner as I had noted those for myself to check.

  • Are workflow units predefined for actions like “search for…” etc or are the workflow units calculated run time on the basis of actual processing done by those respective queries?
  • If a query is used at multiple places in the page, will it be reused or we’d be charged each time?
  • Similarly if same query is used in a workflow in different actions or even within same action in different assignment expressions or conditions, will it be costing WUs for all those instances?
    • What if at one place we use the query for assigning results to a list, at other place we use count of it, and at other place we use its first item? Will these all be considering same base query or three different queries?
  • If same query is performed frequently, do we get advantage of caching?
  • Do we get charged high even if we have only one row in a table and we run query on it? We maintain certain configurations (the ones that can’t be done via option sets as they need to be changed runtime or which depend on other data elements) in ‘data types’). We need to look up those configurations often for certain actions. Will this cost us bomb now? What can we do to avoid these (Some of these can’t be moved to option sets)?
  • “calculating how much wu each action is taking” must be also a quite cpu consuming thing and it is now happening for each action. Is that itself consuming our own capacity and increasing WUs too?
  • If there is a group/repeating group on a page which has a data source that needs to be searched, does each page load cost WUs corresponding to each of those groups/repeating groups?
    • Does it depend on whether the data in those elements are being used or not?
    • Does it depend on whether the element is visible or not?
  • 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?
  • If there’s a pop up that has some elements with searched values, when the pop up is hidden and made visible multiple times, are we charged for those searches each time the pop-up is made visible?
    • What if this pop up is a reusable?
  • If there is a option set type of field in a data and that field has attribute which is of number, then if we query the data and try to do aggregation like sum of values of numeric attribute of option set field, will it cause heavy WUs/capacity consumption?
  • If I have two data types A and B such that A has a field which is list of B. Now if I already have an instance of A downloaded on page, then if I want a list of B which is subset of A’s instance’s B-list values, then is it better to do a :filtered on A’s B-list or do a “search for” directly on B? Similarly what if I want to access certain fields of A’s B-list?
  • Will making original image that is uploaded in DB smaller reduce the download time of images (when the image to be shown is small)
  • If there is a repeating group that has some content, and then there is another repeating group that is using rg’s content and putting a ‘group by’ on it, will it be resulting in full query again? Will it be doing it on downloaded data? Will it be server side query or client side?
  • Say I have two data types A, B and an option set C. Say, A has two fields of type B and C and a field type ‘date’. Now, say I query for all the data types of A which have the date of today and put them in an RG (say RGA1). In another group (say GB) I set the data type as B and load a specific value in it. And say in another RG (Say RGC) I load all the option set values of C. Now say there is another RG of data type A (say RGA2). In this I want to store only the elements within RGA1 which have the field B as the specific one that I have in GB. So, for that if I set RGA2’s data source as RGA’s values: filtered where ‘B = GB’s value’ and ‘C is in RGC’s values’, will it cost be extra WUs than what would have costed to load RGA1 and GB? Isn’t this a totally front-end activity amongst the data points already loaded? Why should this cost WUs?
    • Similarly if I have a repeating group out of some “group by on some fields”. Now if I want to use this repeating group at other places by putting some filters on dates and other fields used in group by, will that be requery? Extra WUs instead of saving WUs?
  • If I have a query “search for user’s tokens’ count” will it be an expensive query? What if “tokens” can be just a text field? What if it is a list of texts type of field?
  • Since using “current user” itself costs us WUs each time, can we save those WUs by making it as a data source on a group? Or will it have to be custom state?

I have recently discussed a few things with Support on how WUs work when I noticed some absurdities in my logs, and frankly it is becoming more and more opaque and unclear on how these are calculated.

14 Likes
3

The one optimization that I’ve made to my apps, that has saved me tons of WU overall, is to store all search results into a state or as parameters in a custom event.

Storing search results into states ensures that I control when a list updates (or doesn’t) and just skips the whole “will this same query cost me WU?” dilemma. Passing search results into custom events gives me the same level of control in my workflows.

It also simplifies a lot of troubleshooting because the root of the data will always go back to one “set state” action or “trigger/schedule custom event” action.

3 Likes
4

@mghatiya Excellent questions. Thanks for compiling

2 Likes
5

@mghatiya thank you so much for compiling that list of questions, this is great! Will dig into them and try to get them answered.

@ihsanzainal84 thanks for sharing!

1 Like
6

As someone that needs to load a lot of data and filter them heavily, this has me intrigued.

Do you just save the initial search to a custom state and then filter the results further only using the data saved in the custom state?

Also, this method doesn’t have any effect on WU spent for Individual Data request right?

Thanks,

7

When you save a search result to a state, it is saved as a static list. The list won’t update itself in realtime. If that list is of a Bubble datatype, each item in that list will still maintain its realtime properties. I will assume this still does incur individual data requests?

I haven’t tested making individual Things static since for me keeping individual Things realtime is my desired result in most cases.

Yes, I do refer to those states for all my actions, elements and workflows.

8

what’s the impact of privacy rules on WU consumptions?

9

Some relevant threads that highlight the questions/confusions that people have and also raise questions on why WUs are charged the way they are.

Also I had a thread with Support where WUs were charged irrationally for a recursive workflow. I have put some details of that here in this post: [Feature Enhancement] Improved Scalability of Schedule API Workflow on a List - #10 by mghatiya

I am very keen to understand and demystify this workload unit thing.

@petter please let me know if you’d like me to have as one of the contributors or testers or something else in this process of documenting and clarifying WU consumption.

2 Likes
10

Thank you @mghatiya!

11

We are getting close to a major update now, which includes a lot more questions added to the workload FAQ along with the new article series.

Please post your questions that you’d like answered before the update is published, please let me know asap!

3 Likes
12

What’s the WU cost difference between “do a search for - using constraints” and “do a search for - filter”?

13

I don’t understand this. I’ve been waiting since November 15th from an answer from Bubble support over whether this is a bug or feature but apparently the engineering team still haven’t answered (last contact was November 29th). Can you shed any light?

1 Like
14

Hey everyone,

Resurfacing this as we’re working towards improving the workload optimization section of the user manual.

The article series has been moved to a more prominent place in the docs to be made more available to those that aren’t searching for it.

All questions related to the optimization process are welcome!

15

@petter,

I haven’t met anyone who has been able to look at the WU consumption of an action (back-end) and be able to calculate how that action used the number of WUs (see this forum where all these types of discussion lead to all possible hypotheticals of what items from the all powerful chart are invoked for what actions). It also seems all documentation is purposely vague (e.g., " 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.").

How about walking thru a bunch of examples of the most common actions (especially back-end) with concrete examples of what searches are being done and their cost, what # of characters are being retrieved when looking at a specific field of specific records (is it the whole record or just the relevant fields?; is it just the UID for linked datasets as long as the dataset thing isn’t being referenced directly? is it always the UID as that’s how Bubble knows what record?; do the field names count as characters?; is a option set field just the “slug” bubble uses to refer to that value or the display + all attributes or?), what goes into setting a slug (I got 11+ WU calculated that had slight variations in different scenarios that seemed random) etc etc.

Then we can go back and see if the math adds up and if not post questions here…

2 Likes
16

Unfortunately I think the manual can add very limited value. You can provide examples for generic use cases but the trouble is that those generic use cases are extremely unlikely to mirror real world usage and you cant make an example for every possible action and inputs.

What we really need is a WU breakdown in the logs - Bubble knows exactly (well, we’d hope) how much WU each component of an action should cost to calculate the total. Would it be so hard to print that breakdown in the logs along with the total WU usage? The breakdown must surely exist in Bubble’s engine ready to be printed to logs, else how else could the total be calculated?!

1 Like
17

Unfortunately I think the manual can add very limited value.

I’m not sure I agree with that sentiment @georgecollier. Obviously I agree that the metric itself is too much of a black box as of now; but written documentation is one of the things that can help the community get better insights into how it all happens in the backend.

The breakdown must surely exist in Bubble’s engine ready to be printed to logs, else how else could the total be calculated?!

This absolutely needs to be heard, but I don’t have a say in that matter I’m afraid (except to bring the point up with Bubble, which I do).

I reckon WU is here to stay and, like it or not, it has opened up to a lot faster processing than what was possible before, and it does strongly encourage people to build more efficient apps.

But for people to be able to do that, we don’t need one thing; we need a bunch of support pillars for people to be able to educate themselves;

  • better reports
  • more information during the building process
  • more community content
  • more Bubble video content
  • and of course, precise documentation

I happen to be managing the last point, so that’s what I’m focusing on. Writing about corner cases is all well and good, but I’m more inclined to think that the more we can educate users on a general understanding of how the server works, the more users will be able to understand corner cases on their own.

So bear with me – I share the frustration that WU is not transparent enough yet, and that planning can be hard. While I’m rarely taken completely by surprise by what I see in the metrics dashboard, I’m not able to make precise numerical predictions or even accurately verify the numbers I see. So, even if I don’t agree with everything that’s said, I do generally agree that the WU launch and post-work has been… not great. It is frustrating to not be able to check that the math adds up. But this is not the thread for that discussion. This is where we discuss the docs and how I can do my little part to shed light on things.

As people keep saying about AI; the current version is always the worst it’s ever going to be. WU is more transparent now than it was at launch, and it’ll keep moving in that direction. I’m doing what I can to ease that process.

As for the questions/suggestions you list @code-escapeel; they’re great! Thanks! The example you list of “operation complexity” is also too vague, I agree. I’ll do some thinking on how that can be covered better.

WU has an FAQ section that definitely needs work; these kinds of questions are great for that, and I’d love for it to have enough topics like those you mention to start properly categorizing and give some final answers to a lot of the black-box-questions that makes it so hard to to calculate today.

5 Likes
18

That’s true to a certain extent but it’s just the sheer complexity of it all that means that even when it’s fully and accurately documented, to calculate the WU for one particular expression would literally still take ten minutes. Physics PhDs are documented, it hardly means I can understand them!

I of course appreciate better documentation for any area of Bubble but I just bet we’ll see so many people like ‘the docs say it should be calculated like this but my WU calculation is different’.

You’ve got a mammoth task to document this all so I don’t envy you and do appreciate any value that you are able to add. Detailed breakdown of EVERYthing in Bubble that can cost WU should be the first step.

19

You might consider training a language model to answer the questions based on data, rather than compiling a list of answers.

1 Like
20

It’s hard not to agree with that. And your last point is interesting. I’ll definitely give some thought as to how we can shed some light on all the aspects of the calculation, and not just the “entry ticket” cost (to use the metaphor in the manual.

@nocodeventure we actually have! It’s even live, albeit in an early stage. It works for the full manual, and not only for WU specifically though. It’s trained on the manual and core reference (since this is a new built-in Gitbook feature), which means that the material is not written specifically for AI. But we’re working on how we can improve the structure for that. WU is a great example where being able to answer direct questions would be highly useful (as opposed to scrolling through an endless FAQ).

You’ll find it combined with the regular Gitbook search.

2 Likes