A lot of people seeing this, some say it’s from people trying to access pages that don’t exist however I have a site with next to no traffic seeing the same thing.
It’s not going to show retroactively. Their system writes the WU into the action as it happens. You need to look at todays WU to get a sense of the change.
A number of these are common paths to access assets and plugins on a Wordpress site. What you are seeing are bots crawling the web trying to find sites with vulnerabilities.
3 Likes
As of now I do not know how to find which parts of the app are inefficient compared to others without normalizing the results to make up for traffic/usage. Which would be time consuming and difficult to determine for every area of my app.
@josh @emmanuel, when we get an improved chart to lookup WU consumption can we also have metrics of which areas of the app are the least efficient at consuming WUs?
ie workflows/searches WUs based on per initialization / per page load / # of times run
Right now when I lookup what is using WUs it is an absolute number which usually is just showing me which parts of the app are most used - not necessarily that they are inefficient. While this metric is useful I also need to track down inefficiencies which this does not show.
As an example, I have a page that I know gets a lot of traffic/usage and it understandably is using more WUs than other areas of my app.
But if I have another page in my app that that all of a sudden gets a a large amount of traffic, then it will only appear on these chart metrics after the fact when it’s total WUs is large enough (after I have paid for all of the WUs). And then it will be time consuming for me to figure out if the page is inefficient or if it was simply a large number of users that caused it to run so many WUs.
It seems unreasonable to have to go through testing every area of my app one by one as a single users and manually track these numbers so I can extrapolate it out for my userbase. And then do this again every time I adjust the workflows and searches to recalculate things and determine if it’s an affordable change.
A way to quickly see this ‘heavy usage per load’ within the Metrics tab would be ideal so I can quickly estimate how much ‘heavy’ pages/features will cost ahead of time to prepare for high traffic situations - which feels crazy to have to do this for every feature but I guess it will be the new normal.
7 Likes
Here a result of one of our apps, this app depends heavily on API rescheduling, it keeps running and makes API connections and update data non-stop.
Prior to the updated Wu calculations, the app avg. Wu usage per hour was around 26K.
After the update went live, I noticed it went down to 5k, then to ~2300 per hour.
That’s around 10x less per what I see.
I will keep monitoring and I will test other apps.
8 Likes
My dashboard is filthy with “Deleted Page” and “Deleted Workflow”, for a simple application that I never use. Also if I read the dashboard correctly is Bubble secretly powered by WordPress behind the scenes? Really!!!??? Of all the amazing frameworks, particularly in Node.js they are using WordPress? What is going on? First they botch the statistical analysis by applying a linear methodology to a highly non-linear system. And now if I read the dashboard correctly they can’t even instrument their code correctly. I doubt they even know what they are measuring anymore.
At this point I think their VC backers need to be made aware of these serious leadership missteps through side-channels.
6 Likes
This morning I ran a test comparing the before and after of the new WU calc in production. Key app pages of mine are heavily dependent on external API calls and SQL connector calls. The exact same set of actions took 575 WU’s before then change and then 48 after the change. (Almost a 92% reduction). I did a second test the next hour to confirm. That’s great news.
The next thing I noticed in my API server logs is that 1 load of the page makes the same API call 3 times. I’m guessing because multiple on-page components use the API and the front end is not grouping those into 1 call, or there’s not API/response (e.g. with redis) caching in Bubble’s backend. API call caching would be helpful to reduce costs as well.
Overall, this is encouraging. Thank you for considering the costs of API calls. My app wouldn’t exist if I have to squelch the # of times I call my own API.
2 Likes
A 10X reduction is excellent. As long as they further optimise their inefficiencies, I can see myself sticking with Bubble.
10 Likes
@josh @emmanuel - I think you need to start versioning and publishing your WU definitions so that changes are transparent.
1 Like
The fix is welcome and it seems that most users will be able to accept it with understanding
Now the obvious question is: how can I continue to trust bubble team that they will not update the prices or update the calculation of the WU formulas again?
@josh @emmanuel
How can I continue to trust you after what happened last week?
Please like this post so that someone from bubble team can answer it for us 
13 Likes
This is great news and thanks for clarifying BUT what grinds my gears is trying to fathom why they announce this without having done this optimization beforehand. sorry but ive lost trust in the business integrity because this is not the first time to announce something only to roll back. i know im joe public but equally i didn’t float up the Thames on a water biscuit.
2 Likes
Getting charged for “invalid page requests” is a full non-starter. We have zero control over receiving bad requests. That has to be removed. Full Stop.
7 Likes
So many unanswered questions but if this transition goes through before May 1st I am confident that the Western Union will acquire Bubble
3 Likes
Since the change is not retractive, I think we would all appreciate to have at least 1 or 2 months to fully evaluate the repercussions of this changes. Please extend the May 1st deadline.
However, I still think this WU pricing is a big mistake from a marketing point of view, since analyzing it is a highly technical task and its not coherent with your vision, nor with your main target audience who are here precisely cause they don’t like technical tasks.
Only Bubblers who have some technical knowledge will take the time to further investigate, ask questions and give you good comments. Ask your self, where are the others? Probably, they won’t even take the time to try to understand it and leave without even commenting because they just don’t know how to debate about this.
Just a suggestion. Simplify.
7 Likes
To throw my experience of price change into the hat…
Yesterday, I set up an isolated workflow on a standalone app. This workflow did the following things:
- Made a call to an AWS Lambda function
- Within this function, three further get requests were made to our database
- Return from AWS, including a pretty hefty string in excess of 50,000 characters
- Create new database item and save this string to a field.
To complete this task yesterday equated to 36 workflow units. Today, this same task is calculated at 2.9 workflows units, a 90%+ reduction.
Similar reductions in workflow unit consumption has been evident across other workflows that also make API calls, alongside similar findings posted above.
Maybe sleeping a little easier tonight….
10 Likes
What the heck is going on? Can somebody answer? @josh? Anyone?
@dushdan123 @aaronsheldon Are those pages showing up if you click on only today? Or might even have to wait until tomorrow. Those are nonexistent pages that bots were trying on your app that are supposed to be fixed as of today
Also why are we doing the Q&A session and not @josh ? I could literally be making up anything right now and no one is here to correct me
1 Like
How do we change the time range constraint for the data displayed? I do not have an ability to. Everything is set to just show last 30 days and no way to edit that.
1 Like
But we need at least 100x reduction 
1 Like
You can click on the bar of a single day, and it’ll open up the bar graph to show that day’s usage by hour, You can then click on the hour and see more individual divisions of WU usage in a pie chart , and clicking the pie chart breaks that usage down into further actions.