Really appreciate this, @josh. Thank you!
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.
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.
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!
@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 [email protected]
@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.
@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?
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.
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.
It is very responsive at the moment in the Midwest US. - Thanks
Are there any more does and don’ts regarding performance?
What I’ve done so far:
Reduced workflows in my header (reusable element). It was just 2 simple conditional Events but made a huge impact on initial loading time. However, it also reduced the UX a bit.
Setting up Element States with Thing data, and then changing the states when the user interacts with the page. This made the click response immediate. I also update the Thing since I need that data on other pages. This is done in the background and the user isn’t affected. I learned to restrict the use of things and instead use states when make a real time game in Bubble (soon to be released).
I’m still struggling with repeating groups lagging when loading 2 simple rows of text from a database with 2 objects. I have a popup with a repeating group that show a list based on the selection on the page. When the popup is shown it first shows content from the last time it was popped up, and it takes several seconds for it to update with the new. This, even though I tried to preload the repeating group content.
I have a menu icon in the header (reusable elements. It shouldn’t be visible when the user isn’t logged in or when the user haven’t selected object to work on. (Before I handled this through a conditional “Page is loaded”-event making a page redirect, see above). I put made the icon not on page load and put a condition on it to show it when appropriate. This made the icon appear long after the rest of the page (even the repeating group with the images). So now I always show it on page load and have a conditional “Page is loaded”-event i the header hiding it when it shoud be. That may take a while but thats the more seldom used use case so it’s ok. So now the user in the common use case gets the menu fast.
To sum it up so far; make sure UI components are shown first, make UI components respond without database-access if possible, and make database updates secondary since they will be carried out in the background.
Will keep working…
Hey, I am getting saving problems in bubble again. Anyone else experiencing issues? Anything important to be aware of?
Sorry for the issues today–we’ve been steadily working on isolating apps on the shared cluster from impacting each other’s performance, but a corner-case came up today where certain types of heavy activity can degrade overal system performance. We’ve released some fixes to minimize the effect, and we should be able to eliminate it altogether something in the next few hours. You can see the issues reflected here: status.bubble.is
no worries. Wasn’t sure if this was something that was known/common. wanted to bring it up just in case. Thank you for the quick reply!
yep, fair enough. anyway I think we are good now – stats are back to normal, and it looks like the new containment measure works properly.
EDIT: well, I might have spoke too soon – still seeing some latency spikes… tracking them down though.