Is Workload unit consumption completely arbitrary?

Only recently did I experience significant overages on any Bubble app (because Bubble failed to notify us until 23 hours after the WU spike!).

Now that I have dug in, I can not seem to make sense of actual WU consumption for various events. Every time I try to match actions to costs in the WU chart (below), it simply does not compute.

So here’s one specific example. Bubble somehow attributed ~1M WU over a 90 minute period for… wait for it… :drum:Setting a SLUG!!

I have seen some forum topics about how Slugs are higher WU than one would expect because there is a search for a unique value (I am not sure why Bubble has not bothered to add that to the WU chart), but no matter how hard I try, I can not figure out how setting ONE Slug can be more than 10 WU!

Please explain how 10 WU is possible. Round up or overestimate any Activity you want, but how can we even get close? (this overcalculation resulted in 1M overage! in 90 minutes [ I can’t look back to any previous spikes as the logs crash every single time})

    NOTE: The actual slug value is simply the slug of a single linked record (not a list) to which a text value from this record is appended, so there is no need to perform an actual search to obtain the actual slug text.

Here’s where I get stuck on my calculations:

  • DB Search: .3
  • Item written to DB: .5
  • **Total: .8**

    Actual WU: 10.83
    Overcharge percentage: ~1350%.

I'm trying to give Bubble the benefit of the doubt so please help me understand how it got anywhere near 10 WU!?

6 Likes

Over a year since update and notifications are still broken, 6 mo left until everyone is forced off legacy :sob: if we don’t have some stability by then I’ll be forced to switch no code tools.

In terms of your issue

Did you file bug report? If not you’ll need to. Last two reports of WU issues I had took over 2 weeks to get answers, good luck :joy:

Is there any chance that you’re running calculations to get slug value or referencing any other records to set slug? Is this front end or back end?

Also I’d assume on bubble side a slug is just a text value on the record, my only assumption as to why it cost so much is they don’t allow duplicates so it’s probably pulling all records in your DB to dupe check :thinking: thus costing 0.0015 per record pulled to dupe check. This is only a theory

When you get response from bubble please tag me :smiling_face:

4 Likes

Also…why did it take 62 seconds for the slug to set…

1 Like

this caught my eye as well!

:eyes: :eyes:

So I considered this Cost. But to get to the max number it would have to be 669 records returned which is bonkers as that means Bubble doesn’t know how to use Bubble (Do a search for thing where slug contains this thing’s propose slug:sorted by slug DESC:first item) will always give the one result needed and then just increment the number at the end of the slug (or if there is none, append “-1” to the proposed slug).

Also if this is the nature of the cost then everyone better be refunded for all Slug WUs as there is no explanation of such charges and nor were we able to itemize the charges.
adding more chaos is that the set a thing slug varies greatly in terms of WU

Also in terms of actual WU here are the 2 actions of setting a slug (I obv deleted those actions as they weren’t necessary) but we are at a sliver under 1.6M! all for a stup slug.

image
image

And the complicated multi layered algorithm that I optimized and reworked because of WU concerns is this tiny sliver :):
image

1 Like

Yea it 100% wouldn’t make sense for them to have to pull all records :sweat_smile: but I’m kinda pulling at strings bc 10WU for a slug set based off info given is insanity :sweat_smile:

2 Likes

Of course I did. And still haven’t heard back on the broken WU spike notifications from March 22, so you’re luck to get anything within approx 2 weeks!

And then there’s this ominous auto reply from submitting the bug earlier today:

image

Isn’t the support team always severely short-staffed? Is this just the standard message or does it mean there’s ZERO support until April 22?!

2 Likes

Agreed. Hope you’re right as that would at least mean some rhyme and reason and would trigger full refunds / class action ASAP.

1 Like

@nick.carroll :pray:

emails are not reliable for this kind of notification. even if bubble send them correctly at the right time the delivery time is not necessarely instant and depend on multiple factors not controlled by bubble or us. The notification should be sent to a webhook of our choice, so we can setup the best notification for our needs.

9 Likes

I think we all agree to that (instead I have the emails triggering webhooks :)) but at the very least send out the emails immediately (or within minutes)…

1 Like

Don’t worry, if you use enough of them, you’ll get a helpful Sales person in your inbox offering you ‘help’ which is really just, ‘pay us $40k+ for a dedicated plan’ and we don’t have to fix any of the WU things.

The main issue with WUs is that Bubble itself has no incentive to make the system work, it is all a funnel and that is a shame. It will be interesting to see what happens when the legacy plan deadline comes about but all of these horror stories of overages and non triggering warning emails don’t fill me with a ton of enthusiasm for the future.

4 Likes

Meanwhile all their major competitors are offering self hosting and code export options or at a minimum hosting that isn’t crashing multiple times per week :grimacing:

7 years total in bubble and regardless of the massive improvements made this last year has been been the worst one yet because the core of their product is unstable.

4 Likes

Incentives = making customers happy and compliance with basic laws (you can’t charge for something that isn’t listed in your chart of charges).

@stuart8 you are right it doesn’t seem to be a sufficient incentive but if that’s the case, we will make sure to make it sufficient incentive.

1 Like

:disappointed_relieved:

4 Likes

That seems to be the case. I’ve been trying to get @josh to reply for a few months now about what he stated when WUs were first introduced regarding a needed feature to allow us to isolate which data fields to return when performing a search since we are charged per character, that adds up, and for some of the built in fields we likely do not need for a search result display to users, we are getting charged for something we do not actually want.

Oh but they do that already.

From support staff below

Our engineers have confirmed that data trigger checks, and their associated workload usage, are expected behavior. I’ve gone ahead and personally flagged to our Product team that this may not be clearly indicated in our documentation as you mentioned. We truly appreciate you flagging this to us as it helps us ensure that we are as user-transparent as possible!

To answer your questions, the expected WU expenditure of a data trigger scan would be about 0.5 WU plus whatever WU is needed to evaluate the condition (e.g., if it queried some data to evaluate the condition, it will take additional WU). This data trigger scan will be done whenever changes are made to the database even if there is no database trigger change associated with the data type that was changed.

My apologies, the amount should be 0.05, not 0.5 WU which was a typo on my part

So, there is no public disclosure on the cost sheet about a 0.05 WU consumption for a database trigger scan when we create, modify or delete a data type that doesn’t even have an associated database trigger event in the app.

If engineering is able to confirm that the charges incurred for database trigger scans is expected behavior, why do users need to submit bug reports about them to have a support agent flag the fact it is not listed and that Bubble is failing on the user-transparency they state they are striving toward; why wouldn’t they just sit down with engineering and say “What all incurs WUs and how much WUs?” and then just make the list to be inclusive and exhaustive of ALL things that incur WU costs? @payam.azadi

I imagine you are correct, that they are checking every single record of the data type to see if the slug value already exists, since it needs to be unique, they need to ‘scan’ all to check for uniqueness. And I imagine that they likely have no incentive to optimize that, so likely every single field value is returned for every single record that is getting checked against which means there is also the 0.000003 WU for each character returned for each data field for each record.

If they are checking against all records, but are not returning all data fields and have optimized it to only check for the slug value of each record, then Bubble should be putting that feature into the editor so we can eliminate the return of field values we do not require for a search, something @josh stated was on the list, but maybe somebody scratched it off.

They would have been smart to focus on performance and stability before jumping into the whole AI craze…HEY LOOK A BIRD!

6 Likes

this is crazy.

2 Likes

If that’s actually the case then all overages must be refunded pronto or it would be time for #breakBubble

However I don’t think that’s the case. I see the same exact attempt to set a slug (value = “0work”) a few seconds later using 75% les WU.

So it wouldn’t make sense that the WU is for the search. I have a hunch I know what it is, just need to confirm a few things and then I’ll post the theory and the math…

2 Likes

Ok @boston85719 @chris.williamson1996 .

Did some heavy testing. Bubble seems to make it harder by the whole log situation (no exports, pagnation, WU filter, and I still have no idea what any of the filters actually mean).

Basically, the major WU spike is from there being thousands of records that have the same slug (as volume increases the WU hit is less but it’s not a computable slope).

I played with it a bit and was able to optimize it to be less WU than Bubble, but not by a whole lot (like ~20% when there that many duplicates).

Besides for no info on this anywhere in all the WU documentaion and the WU numbers being outrageous, to me, it’s about how flawed the whole Set a slug is. For starters, the fact that setting a slug it has to be a seperate WF action and there are no basic options (what to do when duplicate, e.g., don’t set it or append X) and also that duplicates use the moniker that is allowed elsewhere in the slug.

But to me, and I’m curious if I’m alone in this, the whole point of the slug is to be a unique identifier (preferably readable) to remove the headache of certain duplicates. So if I have a slug, e.g., ABC Company → abc-company and there are duplicates, I couldn’t care less how many duplicates there are or a sequence of when the slugs were set, just the fact that there are duplicates. Therefore if Bubble were to stop the sequential numbering and just indicate it’s a duplicate by appending the UID, all of these issues go away. (OR even if they were to use leading zeros before the count then 95% of the WU would go away).

So I used 3 different approaches to solve for this for a couple of dozen apps (based on how the slugs are being used within the app), but the easiest fix (which Bubble could make native with a 1/2 hour of work) is super simple:

   When setting a thing's slug:  slug value= do a search if this proposed value of the slug exists as a slug for the any thing of this data set: formatted as text: 
   for yes: slug value  = proposed slug value
  for no:   slug value = proposed slug value:append "-" append This thing's UID.

cuts down the WU by up to 90% (based on volume) and makes it very easy to know if an slug is unquie by searching if slug contains “-” or whatever indicator you choose to use.

Ill post more details on the weird curvature of the WU consumption based on volume and other ways bubble can fix this fundamentally flawed Slug setup and other fixes I used as well but just wanted to jot this down before the weekend).

2 Likes

Do you reckon if there weren’t so many bugs (or expected behaviours) to report and WU didn’t require a degree to calculate they wouldn’t need so much support?

4 Likes