Is Workload unit consumption completely arbitrary?

[boston85719]

What is the main reason for the setup you have instead of using the native built in functionality that Bubble already provides for ensuring slugs are unique.

When you run the workflow action for set a things slug, the value you enter, Bubble checks against all records of the same data type, and if another record already exists, Bubble will append a numerical value to the new slug for the thing you are setting the slug for, in sequential order.

I would imagine that your setup is part of the issue as you are performing a search, which is not necessary.

If I have a data type called restaurant, and I set a slug to be the name of the restaurant, my setup is simply to use the set a thing slug and the value is the restaurants name…Bubble does all the heavy lifting for me there, so they will slugify the name and also check against all other restaurant entries and determine if a slug of the same value already exists, and if so, add a numerical value sequentially.

So, if I have McDonalds and there are 2 entries already with slugs

mcdonalds
mcdonalds-1

and then I add a new McDonalds, Bubble will make the new slug automatically to be

mcdonalds-2

I don’t know what they do behind the scenes for that or how it impacts WU consumption, but looking at your setup you are using a Search for the slug value and a formatted as text to evaluate. I would venture to guess the Search is what is the problem, and might not be the setting of a slug workflow action itself.

Also, if you are going to be appending the unique ID instead of a sequential number, and keep in mind the sequential number is handled by Bubble to ensure no duplicates and maintain slugs as unique identifiers, which was an added feature due to cries from the community for an easier approach to human readable URLs for SEO purposes, because unique IDs are not human readable and do not add any benefits for SEO and likely lower SEO ‘scores’, I would suggest just not using slugs at all and just use the unique id itself as that is already a built in field that is automatically populated, since the approach of using a slug with appended unique ID does not get you the SEO benefits the slug feature is intended for. Additionally, remember, every character returned (so each number or letter of a datafield) costs WUs, so when you are taking the unique ID (that already exists and is built in, so we can not control that and will always be returned via a search and cost us WUs), and appending that to the slug, you are doubling the WU consumption for returning data values via a search, and from the way I see it, for no added value, since, again, I believe the slug is for SEO only and not just for unique identification of entries (it is unique, but we already had unique IDs).

In my apps, I do not use slugs on data types that will not be used for SEO purposes, and any data type that will not have a ‘unique page’ where that page is part of an SEO strategy, I just use the unique ID.

Have you tested setting the thing slug without using the Do a Search approach and just simply setting the value to the proposed value and let Bubble append a sequential number? I’d be interested to know if you experience the same WU consumption.

[code-escapee]

If I wasn’t clear the ~11 WU WAS for using the built in slug feature letting Bubble doing all the work.

The three approaches I used all come in st under 3WU! which is why i wrote them so ppl can have easy workarounds to save on WUs. They arent exactly hard for anyone who has any Bubble skillz and for me were well worth it to save millions of WU a month. I tested optimizng the slug in the.method bubble does it natively and was able to get WU to ~20% less than what bubble was using to do it but its a lot more complicated of a query and the WU is still way too high. Its a shame it needs to be done at all but I wasnt gonna wait around for Bubble to fix it.

and like i said it &only takes one simple conditional* and in apps where slugs are used on crawled pages i just do the same conditional with a sort that adds leading zeros and still save over 70% on WU when there are thousands of dupes.

[boston85719]

okay, so the above was less intensive on the WU consumption compared to just allowing bubble to do it natively? That is WILD and a REAL CONCERN as it would indicate some serious flaws in Bubble code base

[code-escapee]

Yes it reduces WU by 70% using that workaround ONLY when there are hundreds of duplicate slugs for a certain value (otherwise Bubble’s native slug function is slightly more efficient).

The reason being that without leading 0s you can’t just sort and take highest value and +1. Which is why i solved it (in one scenario) just by adding leading 0s

[laura.oppenheimer]

Hi all,

I’m Laura, the PM focused on monetization – as part of that I’m also the PM who owns things like WU charts, alerts for WU consumption and more.

1. Specific answer to the original question: I don’t know! But please do get in touch with our team. I assure you that we do look at these and anything that’s a bug heads to my virtual desk to fix. Overcharging people for WU isn’t good for us (because it would create scenarios where people don’t trust us - as I can read above) or for you (because no customer wants that). I definitely want to see what’s going on if our success team IDs that something isn’t working as expected.

2. Alerting for WU. The alert does not consistently go out on that - this is sporadic and unfortunately ongoing. Every time someone writes in about this we try to investigate why it isn’t working as designed – a few weeks ago we made some changes that we thought addressed the issue. It sounds like it’s still ongoing and that’s not good. Again, our team would be happy to to investigate but we need all the info to do that (I recognize that it’s a pain to submit sometimes but the reason we ask you to do that is because formally submitting something ensures that all the relevant data - app name, date of spike, when the notification went out, the specific workflow in your app - is there.

3. Better alerts/tools for handling spikes. We aren’t good enough here, yet. This work is slated and we’re tackling it from a few different vectors. More here soon.

4. Our support team: Last week, all of the Bubble team met in NYC as a team (we do this twice per year). This time is so important and in fact I spent some of my time working with folks on our team to discuss this exact topic (WU alerting and what they see). This does also mean that people eventually need to travel home if they aren’t NYC based, which is why there may be delay in response, as plane WIFI isn’t always reliable.

5. In general - as the PM in charge of monetization, the last thing I want to do is create incentives for customers to leave the platform. We need to build better controls here. We need to do better. We’re working on it. I know that can’t come soon enough but please know that there is more we can and will be doing here and that my DMs are open if you want to share more.

-Laura

[georgecollier]

@laura.oppenheimer

Alerting for WU. The alert does not consistently go out on that - this is sporadic and unfortunately ongoing.

Is it triggering the notification flow in the first place that’s not happening right now (so if you added a webhook, that would be triggered late just like the emails currently)? If the delay is in what happens after Bubble begins processing the notification (sending emails and doing whatever else it does), the webhook is the fix we all want.

[code-escapee]

@laura.oppenheimer, thanks for replying. much appreciated.

Some follow ups:

1. Given the multiple bugs with WU calculations that Bubble is aware of and, more importantly the alerts, how can anyone be charged for overages?
   Bubble knows the alerts aren’t going out properly → overages can’t be charged.
   Bubble doesn’t really know what the WU should be for a an action (as we have collected dozens of support emails stating that more or less) and refuses to provide any hard and fast rules about what costs what → overages can’t be charged.

Overages can’t be charged 1) from a customer service standpoint (its Bubble’s fault, not the customer’s and certainly not the developer who is being penalized for Bubble’s issue) and 2) from an ethical perspective (Bubble created an inherent conflict where Bubble makes more money (a lot more) the worse the WU alerts and the more bugs there are) and 3) from a legal perspective.

How does Bubble not see that!?!

And this mislabeled waiver (spoiler alert: It’s NOT a waiver) is far short of the minimum Bubble must do (especially from a legal perspective)

2. In terms of the actual 11 WU per setting a slug, after much time, I fixed it as I wrote above, and it’s not a bug persay with regards to WU. Due to the lack of any explanation of the WU chart and what the actual line items mean or what actions use how much of what I assumed it was a WU bug but in fact isn’t. Just a fundamentally flawed way how bubble sets the slug that can cause huge WU costs in certain situations.

3. I still haven’t heard any meaningful response to the March 22nd buy that I messaged you about.

4. It’s hard to reconcile that Bubble cares about the WU bugs or any bugs for that matter with how annoying it is to file a bug report and the delays in response and the lack of any clear answers / solution.

[sudsy]

@code-escapee

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%

Are you aware of the built-in slug conditionals to check for duplicates?

I wonder if they would have a performance or WU advantage.

[stuart8]

I say this in the nicest possible way, why the heck isn’t Bubble testing things before putting them into production?

What kind of product risks charging customers thousands of dollars and using live users as guinea pigs and somehow thinks that this is entirely acceptable? It really isn’t.

Users should not be the testing ground for all of these issues. The fact that Bubble seems to think that it is acceptable that they are and that these issues haven’t been fixed in over a year just shows that it isn’t a priority for Bubble.

The fact that Bubble does not test these things themselves makes me think that nobody on the Bubble team actually has created something with Bubble where they can test their own WU system to any degree.

You seem to be fully aware of these things but they aren’t fixed. It’s been a year, I don’t think it is unreasonable to ask why not and why isn’t this a priority?

[code-escapee]

Good point. To me its basically half a dozen of one or 6 of the other. I was generally using conditonal ifs as i was using leading zeros but your point is appreciated.

Ill test WU (unfort too difficult to test performance) and report back

[code-escapee]

@stuart8

What kind of product risks charging customers thousands of dollars and using live users as guinea pigs and somehow thinks that this is entirely acceptable? It really isn’t.

It really really isn’t (sorry one really just didnt cut it for me) and is 100% not legal.

This short sighted money grab, (distinct from other money grabs that are legal just not right) is going to blow up in Bubble’s face very soon if they don’t voluntarily put a stop to it.

[code-escapee]

@sudsy did some basic testing. As I assumed, the WU consumption is the same using either approach (slug can have vs conditional [if count of things that have slug value is 0]).

At first it seemed that the conditional method was much quicker performance wise for non-unique slugs (see table) but as I retested setting a slug that wasn’t unique the time came down significantly for both methods. I don’t know if it was because of better indexing as the original slug was set longer in the past or what not …

bottom line: both methods have the same WU consumption. Performance wise, the conditional method MAY be faster but that’s inconclusive.

EDIT: Table

[julian5]

Have you heard anything back from Support re: the cost of setting slugs?

I’m running a simple test. I have a workflow that deliberately sets duplicate slugs.

I started here where the appended number is about 20:

WU is 4.43

When appended number is 60:

WU is 5.68

When appended number is 100:

WU is 6.30

Trending up?

Then I got tired of clicking and made a backend workflow to start cranking that number up to 1,000…

At about 260:

WU is 6.95

Holy man it’s so slow to iterate on lists…

At about #400 …

WU is 7.51

My boredom level of watching a number slowly increment is reaching maximum AU (attention units)…

And about about 500:

WU is 7.58

Attention Units depleted.

I see a linear-ish relationship between setting a duplicate slug, Bubble calculating the appended number, and WUs consumed.

Someone mathy can probably calculate it based on my numbers there.

Okay one final bonus data point:

At about duplicate 650, the WU cost is 8.13

Note:

The WU cost and duplicate number (appended number to slug) is approximate. I’m checking the logs when the duplicate number hits a milestone, so it’s not going to be exact.

[chris.williamson1996]

I’m just curious why duplicates cost such a large amount….are they looping through slug-1, slug-2,slug-3,slug-4, etc until they find one that can be set? If so why and who thought that was a good idea scale wise

I’d imagine simply searching for slug and use regex or another method to find the count of the host slug (slug-1) (only the bold part) then adding +1 would only require a single search cost.

But also that doesn’t even make sense because the above poster is saying 650 dupe records is 8.13 WU to set. Yet 650*0.015 for record pulls is 9.75 WU for the pulls alone…which is more than it’s actually costing…

The bigger question here is why do we have to have a PHD to calculate some proprietary pricing model that no other company or platform uses and bubble themselves keep finding bugs in over a year later.

[code-escapee]

@chris.williamson1996

I’d imagine simply searching for slug and use regex or another method to find the count of the host slug (slug-1) (only the bold part) then adding +1 would only require a single search cost.

Chris, as stated above #19, due to the way duplicate slugs are set up (flawed in my opinion) it’s not a simple regex or sort due to lack of leading zeros. Instead a bunch of searches need to be done IF the root slug isn’t unique (e.g., does root-100000 exist? etc).

I was able to optimize it to be ~20% WUC les than Bubble’s native slug but that reduction isn’t sufficient which is why I went with the approaches I offered above.

@julian5 Nope I didn’t hear back nor do I expect to both because of the way which Bubble handles support tickets (saying our feedback is important but acting as if it isn’t) AND because I’m quite sure I have a better understanding of WUC with regards to slugs than anyone at Bubble given the responses they’ve provided in this threat and others regarding the usage of WU.

Julian, the quickest and sure way to avoid randomly getting a 1M WU spike like I did is to use one of the methods above or any other that essentially determinesa the value of the slug before telling Bubble what to set it to.

[julian5]

@code-escapee

Julian, the quickest and sure way to avoid randomly getting a 1M WU spike like I did is to use one of the methods above or any other that essentially determinesa the value of the slug before telling Bubble what to set it to.

Thanks @code-escapee . The bummer for me is that I wanted to leverage the slug duplicator logic (bubble enforcing uniqueness and appending an integer) for something else (generating unique sequence integers).

But since the WU cost is both baseline high and grows over time, I can’t.

[code-escapee]

Yeah I did exactly that for a bunch of apps when i updated everything last week. the way to do that is to just add leading zeros and sorting by slug and then incrementing by one.

Tldr: IF slug root is unique set slug to root-001; ELSE set slug to find slug root- sorted by slug desc:first item split by:- formatas number add 1.

[julian5]

That isn’t guaranteed to be unique because of race conditions.

Two workflows could find the same reference slug and try setting it to the same next increment:

1. Two workflows start about the same time - Workflow A and Workflow B.
2. Both workflows find SLUG-001.
3. Workflow A finishes and sets the slug to SLUG-002.
4. Workflow B finishes and tries to set the slug to SLUG-002. Bubble sees the duplicate and sets the slug to SLUG-002-1.

You wind up with a mess like this:

@vladimir.pak ended up using an external solution with AWS to deal with this problem.

Maybe I misunderstood your solution?

[jonah.deleseleuc]

I’m not a WU expert by any means. However, to anyone reading this message, I recommend trying to optimize wherever possible but if WU is something that may decrease the profitability of your app significantly (the margins are small) then I recommend looking elsewhere than bubble. The reason is, as you can see here, it’s not very clear what a WU really costs in all scenarios - you’re essentially trusting bubble to act honestly. You’re also opening up yourself to an enormous headache.

That’s just my two cents!

[code-escapee]

Yes there can be race condition issues but if you can spread out the slug setting (usually it’s not super time sensitive) then you shouldn’t have any issues. Also if you use a different character than dash before the increment number (and don’t use “-” in the root slug itself) than you can easily find any race condition issues (e.g., DB trigger when a thing’s slug contains “-”) and reset those slugs