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:
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.
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)
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.
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.
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. 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.
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."
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
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).
@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.