Maximum Capacity

Hi everyone,

can someone please explain me how to read this information?
What does it means that I had 24 minutes of max capacity? From the second graph it seems that it never went over 10%.

Thanks,
Carlo

1 Like

This means that your application did max out for 24 minutes. When it maxes out it means that you are currently utilizing all the resources your application has access to.

The charts do not accurately display information.

Bubble doesn’t show you max utilization for a time period. Instead, they’re showing you average utilize for each “dot” on the chart. So, if you want to see how often your sever was maxed, you have to drill in to a more narrow period of time (e.g., from 7-days -> 1 hour). Even then, you can’t see when it was maxed for 10 or 20 seconds but at least it becomes less inaccurate.

The 1-hour chart will show you different things than the 7-day chart. You’d think the 1-hour chart would show a subset of the 7-day chart, but that’s not how this works. I know this is confusing and quite limiting because you can’t see the 1-hour chart for a time period a day or two ago. Welcome to Bubble.

PS - @Bubble, if you can’t fix the root problem here, can you at least change these charts to be bar charts because when you display them as line charts over time it implies the timeline is continuous? For example, in the OP’s scenario, the average would be at 100% for a few seconds and the chart should display that. Ideally, can you can simply fix that. But, if not, at least present the time period as a bar chart so it’s not actually factually wrong about what’s happening since you don’t display data on very short periods of time which the line chart implies.

4 Likes

Ok… so it wasn’t treaky only for me.
But what does exactly happen when the app reaches its maximum capacity? Does it just slow down or is it as shut down?

Thank you all for your replies,
Carlo

The server will run at 100% capacity so as soon as it frees up from one task it’ll do the next.

As such, once you hit 100% capacity that means users will often have to wait longer for pages to load, data to get saved, etc. because the server isn’t immediately ready for their request but will instead put it in a queue.

Additionally, at 100% capacity, my understanding is API calls are deprioritized (and won’t run until the server is below 100% capacity again) so they often don’t run in the same order as you’re accustomed to them running relative to other workflows, which can work fine so long as your app is designed to handle this. Furthermore, I believe user’s requests can time out if it takes more than 30? seconds for your server to reply to them – but I’m not quite sure on the details here.

So, barely hitting 100% for a few seconds doesn’t really matter at all. If you have 2x more people using your app than your server can handle at 100% capacity, then it’ll be really slow for those people because tasks will queue and become really long (likely until enough people get tired of it being so slow that they drop off your site).

1 Like

Any idea how many live users can cause such limit?
I know there are lot of factors involved. Just curious to know a number that bubble can handle

Not sure, my site gets around 100 users a day and is fine on the personal plan

It really depends on the complexity of the workflows that are being run.

On a basic dedicated plan, our app would run ~2% usage per user at peak times, so that means we could handle ~50 concurrent users before hitting 100% usage. It may have been higher or lower at times, that’s simply the number we were using at the end to plan server capacity before we moved our more heavily used modules off of Bubble.

Those portions of our Bubble app were quite sophisticated and I would expect many apps to be able to support more concurrent users so long as they’ve been well designed and optimized. Of course, if you’re doing anything with real-time data, loading lots of data into RGs, having individual users load/edit lots of data at once, or doing nested searches then you may not be able to handle even that many.

Would be nice if the community shared these numbers more so people can get a sense for the range.

1 Like

50 concurrent users and Bubble reaches max capacity? That too on a dedicated plan?

That was true for our app with a regular dedicated plan - your mileage may vary.

In fact, I encourage other people on dedicated plans to share their numbers so the community can understand the range.

Additionally, it’s important to note, Bubble enables you to upgrade that dedicated server in increments of 2x. For example, you can have a server 2x, 4x, or 8x the regular size for 2x, 4x, or 8x the price. I believe they cap out at 64x of their regular server, but we were never using that much capacity so we never asked about plans larger than that.

2 Likes

Greetings,

in reading this and planning ahead a little, it would appear that there is no way to set autoscaling (like you can do in aws if you were to build this without bubble) but you’d have to capture the logs and build your own real-time triggered report/dashboard to allow you to buy more capacity… is that what I am reading? Capacity is KEY to user experience for apps that are chatty or have lots of complex workflows… I had a plan for my app, but I am now rethinking the flows to make them into microflows. I personally cannot afford a dedicated plan and am in need of pushing capacity logs into something like splunk and using microstrategy to do the analysis. Otherwise, purchasing capacity in anticipation of need is the only way to do this and the price seems very very expensive in relation to aws direct.

Hi, I appreciate your explanation.
I had the same issue with my app. I already have a professional plan, however the data loads slowly—up to 1 minute 36 secs the logs indicate that I reached my maximum storage time of 222 minutes. The software includes API calls, sophisticated processes, as well as routine backend triggers of workflows. Is there a way to manage this properly. Please share your opinion.
This is the usage log: