Slow Response from Bubble

Same slowness here in USA West Coast.

I wonder if it matters what “pricing plan” one is one?

Is anyone with the “Dedicated Hardware” plan experiencing slowness?

In Kenya very very slow

It was always slow? Compare with another machine, another location if you can, just to be sure, can be internet connection, slow machine, internal hardware problem, your router. Speed test your connection is a good idea.

Thanx for the response,it not always slow, just a couple of days now, let me try your suggestions and see if i can figure the problem out.

@josh Sorry to put you on the spot here, but I think the bubble community wants a response to if these issues were bubble related or not. If you looked into it and if you guys figured out what it was.

We are several people planning to be quite dependent on the platform so it would be nice to have a response from you guys, and to understand if you did some changes to fix it or if you “just hope it doesnt happen again”.

Greatly appreciated in advance.

3 Likes

Hey there–

Sorry for the frustrations; I know how much time and energy you all put into Bubble and how much you rely on the platform.

It’s hard to give a specific response, because we are pretty much constantly fixing bugs + issues. It’s a big, complicated system, and little things are constantly breaking. Over the last week, there’s been at least four separate issues I’ve dealt with the could have caused some of the symptoms you guys are describing. Generally we try to fix them as fast as possible to minimize the # of people who are disrupted.

For the curious, here’s a few of the things that went wrong and what we did / are doing about them:

-An app was repeating a query over and over again that was loading massive amounts of data onto our servers, overwhelming our systems. We blocked the specific query, and are still investigating how it was possible. (This category of problem is fairly common: we have a lot of protections in place to make sure that any one app can’t use up all of Bubble’s system resources on shared plans, but Bubble is very flexible and people keep coming up with new variants that get around those protections.)

-Our CDN hit a temporary error fetching one of our key javascript files, and cached the error, causing it to serve it over and over again even though the file became accessible. I’ve tweaked the parameters for error caching to make sure it doesn’t do this, and am following up with our CDN provider to see if I can get the original error from them that caused this.

-Right now, operations that involve overwriting big chunks of apps (such as copying an app, or restoring an app) use a lot of database memory, because of a memory leak in the current version of the stored procedure language plugin we’re on. This has lead to intermittent issues with app data loading performance over the last couple weeks. I’m in the process of upgrading the stored procedure language to the latest version, which does not have this memory leak.

-We had a bug in our code that if you visited the editor when you were not logged in, it was popping up an error message instead of just redirecting you back to the homepage. Over the weekend, I changed the name of the cookie we use to store login sessions to deal with a cookie name conflict between bubble’s shared cluster and bubble’s dedicated clusters, so a bunch of people were logged out and hit this bug simultaneously.

Anyway, that’s not a comprehensive list – that’s more of a flavor. We generally push new code three to four times a day, about half of which is new functionality and half of which is bug fixes (mostly minor things that at most one or two users noticed, but occasionally more serious ones).

Re: @sagans99 's question, “I wonder if it matters what “pricing plan” one is one?”:

All Bubble pricing plans except for dedicated are equally likely to be affected by these issues. Dedicated plans are less likely to be affected, because:

-They’re on an isolated cluster from other users, so issues such as one app using up a ton of system resources can’t affect them

-Dedicated users control when new Bubble code is deployed to their cluster, so they can manage their clusters’ stability by not deploying new code during particularly critical periods.

As further context, we’ve had a lot of growth over the past 6 months – Bubble has a lot more users, and our users has a lot more active apps, than we did before. This is great, but keeping on top of the operations has been getting increasingly challenging. At this point, I’m pretty much full time on operational work, and Emmanuel spends about half his time fixing bugs and investigating issues, and half his time on building new functionality. So we’re shifting resources to prioritizing keeping what we have working and stable, vs expanding the platform. That said, we don’t want to bring new features to a halt either! (Especially the plugin system, which we plan to continue to roll out over the next few months)

Anyway I hope that helps explain how we’re thinking about / addressing these kind of issues…

24 Likes

Really appreciate this, @josh. Thank you!

2 Likes

Thanks @josh, please let us know if you or the team need any support. I know many people here would love to help out and maybe come on as volunteers.

1 Like

I suspect the dedicated H/W plan is out of reach for 99% of Bubblers, but that many more would use it if it was a bit more affordable.

To use me as an example - I’ve just raised a bit of pre-seed and been accepted to an accelerator but can’t yet justify paying for dedicated H/W until I’ve launched and gained a bit of traction. Gaining that traction is going to be difficult if I encounter performance issues similar to the last week. I’m acutely aware of how users react to app performance.

If the dedicated H/W price cannot come down, I wonder if 2/3 users can share H/W amoungst themselves? This way it’s more affordable, has better performance and more secure. Problems can still occur but the likelihood is far less. I’d totally spend around $200 for 2 apps with this scenario.

I suspect a lot of people would rather pay more for performance than for multiple apps.

@josh @emmanuel

2 Likes

Agree and this sounds like a good idea.

I would definitely like to see more metrics regarding performance of any given app. For example be able to monitor a query execution lifecycle in the workflows. Maybe this can determined from the logs in the plans that have logs, but no idea!

1 Like

@AliFarahat – thanks! We get a ton of help and support from the community in terms of people helping out new users in the forum, and creating learning resources for Bubble. That makes a huge difference, and the more time people spend on it the easier it is for us.

@gregjohnkeegan – on dedicated pricing, so our smallest plan right now is still fairly substantial in terms of hardware, because we want to make sure that apps perform well on it – otherwise it kind of defeats the point of switching. However, we’ve only had users on dedicated plans for a month or so now, so as we get more data over time, we might be comfortable offering a smaller, less expensive starting plan.

In terms of sharing a dedicated cluster between a couple of users, we can certainly set that up if anyone’s interested. The co-tenants would have to coordinate around when to deploy new software, and they should probably agree in advance what to do if one of the apps starts getting a lot of traction and needs to upgrade. So, I don’t know how well it’d work in practice – it probably depends on the people involved – but if anyone wants to try it, reach out to us at support@bubble.is.

@DaveA Right now, it’s not especially easy to break out the performance of any given app on a shared cluster. As part of the work I’m doing on solidifying operations, I’m planning on building some dashboards that offer more transparency into overall Bubble performance and uptime. I have a few projects around database speed and reliability that are higher priority, so that’s going to be a little bit down the road.

4 Likes

@josh I appreciate this eloquent, detailed response.

I now understand the overhead with shared H/W - deploying new software and data/ workflow usage. The people sharing will need a bit of a deployment plan and to monitor usage. In theory, all I really care about is a stable app, I wouldn’t mind if the others sharing used twice as many workflow as I did.

I’m still interested in test driving this, if anyone is interested in sharing H/W please let me know.

I’m interested. What would be key for me is what the split will be in terms of cost. I suppose it depends on the number of people grouping together to do this. Also it would be great to test drive this for a couple of months to see what the gain is in terms of performance and then to make the commitment based on that.

@phuthi Cool. Fellow Saffa here (LDN based).

I’ll send @josh a support request and let’s see how we can work something out. What are you building/ have built?

Am building something that is more of a reporting application. Customers are corporations and access driven by minimum logins being provided per corporation (±5 users per corporation) so it’s not thirsty for resources. Performance however is key. Cool thanks, lets see what can done.

Good to know. Im finishing my MVP and my business partner is looking for capital at the same time. Im in love with the tool so far so i hope you guys can fix this soon. =)

Bubble is extremely slow for me for the last several days. My internet speed is quite good and have no issues accessing other apps. The preview and development screens are extremely slow and it takes as much as 40-50s to load simple page. Any one has any new insight on this problem?

https://testhssapp.bubbleapps.io/version-test/home?debug_mode=true

Make sure you only have installed plugins that you are actually using in your app. Right now Bubble is a bit slow to load apps that have a ton of plugins (like yours), and if you’re not using all of them but just added them to test / experiment it’d be good to remove them for now.

We’re looking into speeding this up in the coming days.

4 Likes

Sounds good. Thanks for the quick response. We are pretty much ready with our MVP of the product and looking to get in to our next step in finalizing the platform of choice for the long term work. Hopefully the speed fix would be in place that we could rely on the long term work. We tested with very little plug-ins and works with the SLA we want to achieve.

1 Like