Hi @josh, I’m sure you will have no shortage of offers of apps to look into, but I have a very basic task management app which is hitting the rev limiter the whole time without, in my view, doing anything particularly complicated. I have limited the “Do a search for…” to almost nothing, so everything is relational, which I would have expected to make a great improvement, but still even loading a page with a repeating group showing just 10 cells can take 10-15 seconds…
I feel very much in @vincent56’s camp here - when I first got involved with Bubble a year ago, I was far less structured/organised in the queries I ran, and never used the Workflow API or reusable groups, where now I use the Workflow API for lots more, and consolidate into reusable groups as much as possible. My slow app is a one-pager, with lots of hidden elements on page load - is this likely to be what’s causing it (eg, is there a chance that some of the hidden elements are looking for information even though they’re hidden)?
Hi @dos this may help you find out where it’s gobbling up resources.
I have found that even employing the API to commit data to the database is likely to make you hit your maximum. I had a method of saving 8 data points on a single commit using the API workflow to capture 8 individual occurrences about 15 to 20 seconds apart. A simple question and answer commit and would max out even though it was super fast. I then created the same commit, same fields and same data (identical) using a workflow creates a new thing and not a blip!
I was able to recreate the same test. So it is clear that employing the API has a higher overhead than using a workflow create a new thing. I just could not get it to reduce the overhead no matter what interval in an API commit. If you are using this API method to create a new thing, I would see if you can move them to a workflow save.
I also noticed that if you load base data into a page that you may use in a further commit the overhead is less than if you grab the data from a repeating group on the fly. And I would try and stay away from having a query in a workflow to create a new thing, this also seems to chew up the resources.
In one way you can use the process to try and reduce the overhead for when you grow the user base, but on the other hand, it does seem that it forces you to build the app based on the way the Bubble metrics are configured, which seems to be sensitive to time, method and number of data points (even on small commits).
I understand that throttling based on the customer’s usage is required, but the sensitivity for smaller commits seems to be an issue and suspect its as much a learning process for Bubble as it is for us.
Also on a final note, look for constraints on your queries which may have a spelling mistake such as "mydatathing = miss speelling. I had one that clearly would not be able to find and this maxed out my resources.
If this is actually true, I feel that something is broken. The very reason to choose an api workflow (at least for the most part) is to allow the user to continue go about their way in your app. If the API workflow maxes out almost on default, it is disrupting the user and not allowing him to go on about their business in your app and moreover it affects everyone else using your app.
So if that is the case, it would be better to move those api workflows back to being regular workflows as they will then only affect one user instead of all.
I do think there is a drop off moment where it makes sense to move from a regular workflow to an api workflow. But for creating lists, there is no other way…
This is what I would have thought too - I understood that using the API would allow the user to go about their business on the app while it processed in the background, whereas using a workflow meant that the user would need to wait for it to complete.
My interpretation of this would be for a faster, smoother user experience using the API, but it seems to be that the opposite is true, according to @StevenM - would love to hear the Bubble team’s thoughts on this - I totally agree with @vincent56 that I’m sure the Bubble team are learning at the same time as us - it would be great to get to an agreed ‘best-practice situation’ which works for everyone.
I had previously taken that best-practice to mean reusable elements and API workflows wherever possible - I’m happy to stand corrected…
@dos yeah I would have prefered to have run updates via the API it was super fast and the user could then move on right away. But in my case, I was able to set it up so that only the first action in a repeating group took a moment but the rest using the same workflow is just as fast. However, I can see where the API would work better in a one page app. @josh did say:
Running an API workflow on a list does eat a fair amount of capacity: each workflow run has some capacity overhead, and creating / modifying items in the database are expensive.
I took a look at @vincent56’s app, and found both a general issue and a specific one. Both issues are with Bubble, not with his app, so we’ll fix on our end. Expected ETA is in the next 1 - 2 weeks.
The general issue is with the capacity system as a whole: until an app is maxed out on capacity, Bubble will try to execute all requests as fast as possible. For small items of work, this is good – it means that as long as long as you have capacity, Bubble is as fast as possible. But for longer things, like doing an operation on a long list in an API workflow, Bubble might use up all your app’s capacity on that, instead of sharing that capacity with other things your app is trying to do.
So, the fix there is that we’re going to make Bubble smarter about how much of your app’s capacity can be spent on any one thing, and which things are more important. So if you have a background API workflow running, we’ll rate limit it so it never takes up too much of your capacity, leaving your capacity free to handle something more urgent, such as a user trying to load the page.
The specific problem – which is related – is with a workflow in vincent56’s app that deletes a list of things. It turns out that deleting a list of things is heavily parallelized right now, whereas most list operations we process things one at a time. What that means is that when we are deleting a list of things we end up doing a lot of work very quickly, so it can consume all an app’s capacity. (Deleting things is particularly work-intensive because we have to track down other items that reference them and delete the references … that’s the part that we are doing in parallel right now).
The fix for that is that we’re going to change the deletion action to be less parallelized, since again we don’t want to use all the app’s capacity on any one particular operation – better it runs a little slower in the background.
Thats great news! Thanks a lot for taking the time. I think those two fixes will be of great benefit to all of us!
How are you going to determine the rate limit?
As for the deletion action. If the next action is depending on the deletion action to have finished, this should not impact that right? It will just be a bit slower in total, but it would still wait for the deletion action to have completed as it does now?
Haven’t worked out the details yet, but it’s likely going to be some fraction of the app’s total capacity. And it’ll vary based on what the operation is – things that are user facing, like page loads, we do probably want to try to run as fast as possible, whereas things that run in the background like API workflows we probably want to limit further.
For the deletion, yes, this shouldn’t change things in a user-visible way. We actually delete references after the fact today anyway, since the item will still disappear from lists / searches as soon as it gets deleted… this means we’ll just do that work a little more slowly.
Hey guys, I made some adjustments to fix the above issues. Specifically:
Bubble is now more generous with short bursts of capacity usage. If your app is only being used intermittently, we let you save up a few seconds of capacity, so the next time it gets used, you get an initial burst of high performance. I’ve quadrupled the threshold for this to let you save up more capacity, so that apps that aren’t used very frequently are less likely to max out because of short bursts of activity.
I fixed the issue with deleting items – we now do the cleaning up of references more slowly so we don’t use too much capacity on it
We now rate limit each individual request / workflow / scheduled thing so that no one process can use up all of your app’s capacity. This rate limit only kicks in after a request has consumed an initial chunk of capacity, so it won’t affect short requests. Long-running operations will get slowed down in order to keep them from eating up all of your app’s capacity. The rate limit is variable, based on whether this is a background task or something the user actively initiates, and the limit is a fraction of the app’s total capacity, so as you buy more, the limit will go up.
The net effect of these changes should be that it’s harder to accidentally max yourself out on an app that isn’t being continually used. Instead, you should get more consistent performance as you scale. The downside is that background / longer operations might take longer to run, but you can speed them up by adding more capacity (even if your app isn’t fully maxed out).
This is great! Thanks. Good to see this fixed so quickly.
Can you say anything in general about how much adding capacity will help in speeding up background operations? This will be important in determining how much extra capacity makes sense.
You can’t add capacity to speed things up beyond the speed they were running yesterday (on a non-maxed out app). Things are limited by the max speed at which Bubble’s infrastructure can process them, so adding more capacity will only speed things up if you are hitting the new rate limits we added today.
The thresholds aren’t exact and we may adjust them over time, but generally if a scheduled workflow is using about 10% of your app’s capacity, or a user-driven workflow is using about 20% of your app’s capacity, it likely is hitting the rate limit and would be sped up by more capacity. At the moment, we report capacity at 1 minute granularities across your entire app, so it’s hard to get the exact amount a workflow uses, but you can estimate with the following: create a copy of your app, so that no one but you is using it; run the workflow (without doing anything else at all – best is to close the tab immediately after starting the workflow); look at the server logs to see how long the workflow ran. If it ran for 10 seconds, and your app reported 5% capacity usage during the minute it was running, the workflow probably used about 5% * (60 seconds / 10 seconds) = 30% of your app’s capacity. Likewise if it ran for 90 seconds, and your app reported 5% the first minute and 2% the second minute, it probably used about (5% * 60 + 2% * 60) / 90 = 4.66%.
Hi @JohnMark, please check your Logs -> Usage charts. I’m seeing a spike in your app capacity usage that perfectly correlates with a spike in number of workflow runs on your apps (look at the last 6 hours to see the correlation). It looks like you’ve had drastically more workflow runs today than you’ve had in the past. I would recommend more capacity for your app based on your current usage patterns.
@josh Hi Josh. Does the new pricing model allow for sharing collaborators across apps ? So if I have a Pro app, does that allow me one collaborator across all my other apps. Or just one on that app ?
Thanks @emmanuel - as I explained to Neerja this seems very harsh on people working on several small apps at once with a single collaborator as it becomes prohibitively expensive.
I don’t think I am uncommon in working on several things at once, which are all “pre live”. And these tend to need some help with UI.
Is there another solution that I am missing ? I am avoiding using my agency plan for personal stuff.
As an example … take buildingonbubble.com which is a low traffic site for bubble tips.
Happy to pay $14 a month for it. But $62 for the sole purpose of occasional help with some UI - that is a huge leap.
I would agree with @NigelG, perhaps the ability to add a collaborator on smaller plans for a small fee the way you guys enable ability to add capacity. This would facilitate help on small apps in development before we release the product, and after all, the better the product we release and higher probability we will be more successful and upgrade the plan!
Definitely support that concern - we run into that a lot in our everyday’s operations.
People are happy to go for the paid package, but as soon as they realize that to add 1 collaborator they would need to pay 50 bucks more, they are at least discouraged.
Simplest solution would be to allow more collaborators (2 would be sufficient in most cases) on beginner tier plans - that would make everyone happy.
But if that would not work for any reason (although I truly believe the above is the best option), then maybe adding collaborators could use a model similar to how adding capacity works? e.g. I dunno - 5 bucks on top of a beginner plan per collaborator, or something like that?
Hi, it’s me again:)
This time I have a question about the bookable additional capacity units. We want to increase our speed and buy additional units.
We want to find a good solution based on speed and price. To test how many units we need, we would first have to test which number would be optimal for us.
Example:
1 unit = $20 increases speed by 3 seconds
2 unit = $40 increases speed by 6 seconds
4 unit = $80 increases speed by 8 seconds
After this example we would like to take 2 units. But we bought 4 for testing and put it back to 2 immediately afterwards. What would cost then?
Best regards
