Another post about performance issues

Question
1

@josh and @emmanuel, on the heels of A fair and honest chat about Performance, I too am experiencing performance issues and I don’t think they should be an issue unless there were tens or hundreds of users on my app. Right now, it’s only me in the development server and I’m getting tons of “app too busy (1)” errors while testing one workflow sequence.

I realize that I may not be building my workflow as efficiently as possible, but I would expect my app to perform better than it is on a “Professional” plan – maybe I’m naive in thinking “Professional” is enough for what I’m buiding. The only process I’m doing at the moment is calling APIs to get emails from a User’s email provider and processing them into Bubble. I’m getting the User’s folder structure and 2 emails from each folder, then transforming images, relating attachments, and some other items. This somewhat simple use case has some complexity involved, but I wouldn’t think that my whole app would be unusable or have the workflow terminated with such a small set of actions happening.

I understand that I may need to upgrade as the app grows, but I’m having hard time imagining what level I’ll need, and cost involved, if I’m already experiencing issues with only 1 user and very little system interaction.

Bubble is amazing, but if I’m only able to build static sites, or sites with very little processing/transaction throughput, I may be better off hiring a development team to build the app on another stack --which I don’t want to do, but may be forced to based on cost and performance limitations.

So, are there any suggestions you could provide to help? I realize you’re a small team with a large base and a huge list of to-do’s now, but I hope that there’s some fix for these issues or insight into what I’m doing wrong – outside of “you’re a dummy Keith and need to upgrade to a Team or Production plan”. :slight_smile:

2 Likes
2

I am having a lot of issues like this too. Hope to get help, I didn’t get any response on the forum when I asked though.

3

In general ‘app too busy’ means your application was maxing out its capacity (and that the workflow took too long). While we work hard to make Bubble more efficient and improve what one unit buys you in terms of how much data it can process, long workflows that process a lot data or that connect to external services do take time, and require more capacity. Bubble lets you build complex logic and these steps can take time.

Looking at your main app, it’s been rate limited for more than 200 minutes over the last 24 hours, which explains why you’re having these issues. You haven’t added capacity to your app, I recommend adding some units to avoid these ‘App too busy messages’. If you do, you’ll see much less of these messages. And that’s why we offer the option to add capacity units…

4

Thanks for the quick response @emmanuel. I have performed a lot of testing in the last 24 hours, so that’s why it’s maxing out capacity, and I recently migrated from the legacy plan to the new plan and added Professional, hoping it would alleviate the performance problems, but it hasn’t.

My concern is that the app won’t be able to support users without paying $100 extra per month every time I add a new user.

5

I would recommend testing (also, keep in mind we prorate fees when you add/remove capacity). Depending on your logic you may need more units, but in general we’ve seen many apps with serious traffic using 4 to 10 units, and not 5 unit per user. Once you’ve calibrated your needs, you can look at your workflows and simplify them, make them work less on lists, etc.

1 Like
6

I added 5 additional units, which I think makes my monthly cost $169 and I’m still getting “App too busy (1)”

image

7

Did you use the capacity analysis tool to see where usage is going to? That will help you refine your logic to make it more efficient. It seems you have a lot schedule API calls on list of things, that can be expensive if the list is very long… (also, the capacity boosts can take 5 min to be visible on your app).

Also, if you see a reproduction pattern, please share how to reproduce with the team.

8

hey @Kfawcett

And are you doing this in one API workflow?

9

It’s a combination of multiple API workflows with a lot of “only when” actions to account for various differences that occur.

Since I’m still in the development/testing phase I’m triggering the start on page load which consists of creating, or updating, the folder structure, then processing emails in each folder.

image

All of the workflows shown below are being used. The purple colors happen first. Then the green, which consists of the reds and greys. Finally the red, which consists of oranges.

image
image.png1557×360 15.2 KB

The page load kicks off the first “createFolders” endpoint, which has a nested “createChildFolders”, the “createChildFolders” has a nested “CreateSubChildFolders”, and so on for four levels total. This part of the process happens very quickly.

image

After the folders are created, I get the emails in the folders which looks like this – note: I’m only getting 2 emails from each folder at this time. This part of the process seems to take a lot of time.

image
image.png1478×340 18.4 KB

Inside the CreateEmails I’m doing some processing on the emails to convert inline images and relating attachments.

So, there is some complexity involved, but it still boggles my mind how long it’s taking to process 2 emails from each folder.

In addition, until there are improvements in the logging system, it’s extremely hard to tell what’s taking up the time.

  • How long is it taking (in milliseconds or seconds) to complete each action in the workflow?
  • Are there long running queries?
  • Is something waiting to time out?
  • What is the actual error being reported from the API I’m calling?
10

Forgive me if this is dumb question, but have you tried incremental testing. What I mean is start with the first process only. For example, this might be create folders and stop, then check out the performance. If all ok add the next process, which might be get the emails and stop, then process emails and stop, etc…

Then at least then you may find out at which point the resources jumps.

1 Like
11

That’s a great thought and I’ve done some of it, just not completely.

12

Performance issues have really been on my mind ever since I got closer and closer to finishing my app. I was (still am) building an app for students to submit proposals and pretty much a lot of data processing. (I can’t share many details about the purpose of this app)

I read about other performance issues that people were having and having my app slow to the point where it’s unusable wasn’t really an option for me and this app was going to be used by over 400 students in 3 different schools and many users will be using it at once.

So, I ran a test, I hired volunteers to test my app (we were on the Personal plan) and they all had the task to fill out a pretty basic form and submit it and then they would go to other parts of the app and submit other forms.

What I noticed is that, it was slow, when users hit the “Submit” button, it took a good amount of time for it to submit and redirect the user back to the index page (If you’re wondering, the workflow was to create a thing in the database which stores everything the user wrote, made a change to the user, sent an email and redirected them back)

If my app wasn’t going to handle 5-10 people submitting a basic form then how would it be able to handle data of 400+ students?

We considered separating each school to have its own app but then we would be paying around $207) per month for each app, which if you factor in the fact that my local currency is not US dollar and currency conversion fees because Bubble uses Stripe, which side-note, please consider adding PayPal, is a lot of money.

So, why does Bubble promote itself as a “money saver” (because theoretically, you don’t pay for Web Developers) when your app grows, you’ll be forced to either shell out more money than you would if you pay a Developer to re-create your site or leave the platform completely.

TL;DR
I was just as lazy as you and couldn’t write a TL;DR. So just, take a few minutes and read it.

13

There are a lot of ways to submit a form, some better than others. Its not only about real speed but also about perceived speed.

For example, you could already create the Thing when a user opens the form. You can divide the form into sections (for long forms always a great UX best practise). Each section would have a next or back button which could save a portion of the response into the earlier created Thing.

Upon final submission there is little left to save so the entire process seems quicker. As a benefit, you are already saving some data that could otherwise be lost.

Another solution for perceived speed and would work particularly well when the user doesn’t need to see the data right away is to schedule an API workflow to create the thing with all the response fields. This way, submission and redirect are instant and all the heavy lifting happens server side and not client side (where they have to wait on the progress bar).

These are jut a few examples of all the possible options to explore when building out a seemingly simple solution.

And this is what is exactly the problem with Bubble imo and has been addressed so many times already by users and the Bubble team. Bubble is incredibly open, which is great. But it also allows people to setup apps in a less than optimal way. I have been debit to this as well.

The team is doing an incredible job in my opinion to keep optimizing backend processes and communicate transparently about it. Compared to a year ago even the stability and performance has increased dramatically. I can only see this improving further. The community is also actively searching for ways to improve performance and that is interesting to follow too.

3 Likes
14

@vincent56, you’ve provided some good ways to improve perceived speed for some, but for my issue everything should be happening server side, so it shouldn’t effect the end user’s experience very much. Unfortunately, that’s not the case.

As backend processing is happening, the entire app’s performance is being degraded. To the point where it’s taking 10+ seconds for pages to load, since it needs to grab data from the database, or the user is presented with an “app too busy (1)” as the only item on the screen. Othertimes, the page is loading, but repeating groups are missing/not loaded.

It’s possible that there’s a combination of issues happening right now – Bubble platform issues and my app trying to do “too much” for Bubble to handle. The odd thing is that I didn’t experience these issues a few weeks ago and I haven’t changed too much in how my workflow runs, so it leads me to believe that the issues are more on the platform side, than with what I’ve developed.

15

It would be great if each app had the capacity divided and reserved between scheduled workflows and real time actions. You could queue intensive actions to the backend by scheduling and make sure less intensive actions like navigation and simple workflows have reserved capacity to keep operations up and are not impacted.

Or maybe something similar to the SETI app that only processed data when you were not doing anything with your computer but at server level. So run this scheduled workflow when usage is below X.

2 Likes
16

Has there been any further development regarding speed?

I have a form with 10 input fields including dropdowns, but it takes around 20 seconds for the data to be displayed once the workflows run. That’s just too slow. I like bubble but, I’m used to the speed of typical web forms, which run on php, the data capture and process seem instantaneous. It’s there a best practices to follow, instead of perceived speed tricks?

17

There has got to be more to this story. How much data are you trying to load? I’ve never had anything in my app take more than 20 seconds to process unless I’m dealing with over 1,000 records being manipulated at once.