Helping each other understand WUs and optimizing our apps

my create workflow is

I loaded the page, then created 10 things and goth this result:

It’s a total of 11.4WU for 10 things.
1.14WU for 1 thing created.

I don’t have a screenshot of the logs, but the WU breakdown was not available yet in the app when I did the test.

Maybe the difference is that I just created 10 things without any other action in the workflow., while you also modified another thing.

I am really trying to simplify things to help me understand how to effectively optimise. Basically, I am trying to see if using the /bulk endpoint is more efficient than adding the same data one at a time or whether it’s the same resource consumption.

I’ve created a test page with a single button that has one action. This adds a new row with 2 fields as shown:

I’ve clicked the button 10x and it creates 10x rows. Each time, it is consuming resource as follows:

Button click = 1.13 WU
Action/create = 0.63 WU

So it seems the button click is consuming more resource than a db INSERT. Is the solution to remove all buttons from my app? (joke)

If I turn to postman and use it to simulate 10x API requests (via the /bulk API), it doesn’t even register in the logs… so I will need to isolate the time I test this to measure the results properly (I’ve been testing all sorts on the API in the timeframe) but it feels less expensive.

Does anyone have any insight into this? Creating a thing via the API seems very fast and inexpensive so perhaps I could store up the requests on the client side then fire it off and create it all at once via the bulk API. I’ve no idea if this would compare for deletes/updates.

AFAIK, Bubble have so far, released very little about how to optimise apps to maximise cost efficiency (cynical opinion - why would they?) so leaving everyone with next to no information and 2 1/2 weeks to optimise yourself leaves a bad taste - just do us a favour and increase the WU’s to give everyone more time.

1 Like

In my test results post I’ve added result for testing only 1 thing creation without updating another data type:


When I was updating another data type I had 2.75 WU per WF :slight_smile:

Give up guys - it’s gonna take a PhD in marketing, mathematics and corporate jargon to understand how WU’s are calculated. Also, the chart they gave is not accurate and only represent averages (in my opinion)

5 Likes

11.40336WU to be more precise XD
I agree it’s pointless to obsess about it.

isn’t that metric for the whole “create-1-task” custom event? My understanding is that the “finished workflow” has the cumulative metric of every action in the workflow.

Being “finished running workflow” I think that the log for the button click refers to the whole workflow, including the data creation.

1 Like

For “create a new thing” action:
Finished running action (used 0.63 WU)

For the whole WF (which is triggered by a button click and has only 1 “create a new thing” action)
Finished running workflow (used 1.65 WU)

1 Like

Yep. I talked about this here

That is expensive just to create something and could add up very quickly. Task management, chat systems, anything with potentially limitless entries is going to have a hard time integrating into this without hemorrhaging money.

I’ve contacted support about this so I hope they can help solve this issue. Bubble’s got a smart team so I’m hopeful we can figure something out to make this work since there is seemingly no turning back for the foreseeable future.

I’ll check tomorrow if the app has WU data in the logs and see if the numbers there match with the pie

Obviously, costs to create a new Thing are going to vary a bit depending upon what you’re putting in them, etc. Here’s an example of a Thing created in a backend workflow:

0.62 WU for whatever that’s worth and the “Values List” field is here set to an array of 1000 numbers. It does look like one-off Thing creation in the front-end is a little more costly in WU terms. :man_shrugging: That list of values, BTW, was also created in the backend (that is it didn’t have to travel from the front-end to the backend to get attached to this object).

As far as the Bulk Create endpoint: Here’s an hour where I was testing Bulk Creation using my SSA plugin that does that (from today)…

The API slice there is the creation of Things using the bulk create endpoint (both pinged server-side and from the client. Created more that 1000 things (wasn’t trying to be scientific, can’t tell you exactly how many things I created, but probably on order of 1300 or so). WU cost of that slice is 1084 WUs. Anyway, there’s a bit of a discount in creating new things via the bulk create endpoint it seems as, looking at the count of those objects created today, I apparently created many more of them than I thought – 2165, so maybe cost was exactly 0.5 WU.

Edit: they are my demo “Favorite Things” objects and I set a Name (text version of a random integer) and a Value on each (numeric field with that value as an int), BTW.

5 Likes

Well that describes my qualifications perfectly. I’ve created a brief overview video to provide a high-level synopsis so that everyone can finally be on the same page - and in less than 2 minutes. Enjoy!

8 Likes

:rofl:
You dug up a classic gem. Thank you for reminding me of its existence

1 Like

In josh’s latest post it was said that things like the number of records and the number of characters in each record will play a part in WU calculations.

The WTF moment for me right now is why are Server Side create actions costing much less than client side? I mean it’s great to be able to push things to the server side but it doesn’t make sense to me now. Guess it looks like another email to support.

Just to add on, here’s a reply i got from support regarding searching with the :first item operatot.

" Regarding your question about the :first item operator, this would be measured as a “do a search” with 1 result — same as a search that just happened to only match 1 thing. Therefore, as this data type includes more records, this would not impact the WU usage of the :first item operator."

Breaths sigh of relief.

2 Likes

I have a similar log:


It looks like the actual creation action is consistently 0.63WU. The total of the full workflow execution is different. There is probably some small difference like the amount of data transmitted :man_shrugging:

2 Likes

For completion - creating 25x new things through a /bulk API call barely registers in WU’s. On my app, it registers 1.53 WU’s (in total) for 25x new objects created via the /bulk API. I was half expecting this operation to cost ten times that, given a single insert costs 0.5.

Unless I am mistaken it doesn’t register the db create (which from Josh’s update costs 0.5 WU’s per item) for all x25 items but registers the single API call and a single insert instead. (And so it should)

Consequently, this could be a very cost efficient method to add multiple items to a table in one go (better than doing so iteratively/scheduling workflows, for example).

1 Like

“No-code Bubble raises $100M to make technical co-founders obsolete”

However you will need a phd in statistical analysis.

3 Likes

@rjwilkinson10 there is no creation event that gets recorded in the logs (this may or may not be a bug - probablyis a bug), so you don’t see them in the log, but the WUs for item creation show up in the next hourly WU chart. However, they do still seem cheaper (as in the past, when one would say they are faster) than other means of Thing creation. I tested this a bit yesterday (I have a forthcoming plugin that makes dealing with the bulk create interface easier) and it looks like charge was 0.5WU per item created.

1 Like

Yup same, the monthly cost of my app will quadruple in price

Just curious did you check if your WU is lower today? They reweighted all the WUs like 1/10 but it won’t retroactively reweight previous days.

I had a daily workflow go from 9200 to 900

1 Like