It would also be nice to get a guide, or just some guidelines, on which design choices impact speed.
For example, if I have a dozen elements that need to run the same search, is it better to have one hidden element run the search and then have the visible elements reference that hidden element’s value? Is there a difference between one action that changes a dozen fields and a dozen actions that change one field? Does it matter if a long list of changes are hard-coded into one or more workflows vs iterated over by an API workflow?
Thanks for the update, can’t wait to see how these changes affect our apps Would people on the Team plan still need to pay more if you decide to allow a purchasable performance increase?
Thanks, guys, that’s great! Performance is one of the major things right now…
+1 to this.
Re: @philip – "Would people on the Team plan still need to pay more if you decide to allow a purchasable performance increase? "
Probably not. We’re still working out how it would work, but we’d likely use a performance increase as a replacement for the current limits on workflow runs, so we’d probably reshuffle the whole plan structure to take it into account.
Sounds really cool!!! +1 from here
I like this idea. Performance is something more convenient than workflows counting. Workflows are something that can be quite different for different types of applications.
As for recourse isolation in a shared environment, I imagine it is something like that, how it works with CloudLinux OS for Shared hoster’s tenants.
I have a feeling this change has had a pretty substantial negative impact on our app’s performance.
I get more complaints from users hitting errors and I also see more errors like:
Yes, that happens during some complex workflows, but nothing extreme and also by just a few users (mostly me for the taxing stuff).
Couple of questions:
Are users in Europe more impacted by this change than users in the US (east)?
Is there a difference in resource allocation for the different plans? I think it’s fair that apps on a higher plan get more bandwidth (as those apps probably have more users, workflows etc.)
The dev version as well as the live version of each app are affected in the same way? So if the dev version is very busy, that affects the live version?
I hope you get those speed plans up soon because I’m a little woried about this step. Especially when I read that average page loads will improve slightly while ‘best-case performance’ and data-intensive operations are significantly impacted.
Hey @vincent56, sorry about the negative impact – we’ve definitely seen this come up for apps that are more data-intensive. We are currently working on some changes right now to try to mitigate that impact as much as possible, and you should see some improvements as soon as this weekend.
On the plus side, since we made these changes (about a month ago), we’ve seen a vast increase in overall system stability – on average, people’s apps are going down much less than they were before.
In answer to your questions:
There should not be a difference in how these changes impact European users vs US based users. This is all about consumption of server resources… latency between the web browser and the web server shouldn’t have an effect.
No, there is not a difference in resource allocation between currently existing plans. One of our top priorities is changing our pricing infrastructure to enable buying capacity a la cart, so that low-usage apps don’t need to pay as much as high-usage apps. We’ll grandfather existing users into their current plans, and give them the option of switching to the new system, so that everyone can pick the option that works the best for them.
Yes, dev + live versions of the apps share the same resource pool. We considered breaking them apart, but, like workflow counts today, we decided it would be easier for users to share a common pool (some people need to do intensive stuff on the dev version of their app)
Anyway, the worst is over with – any negative impact this change will have has already happened, and like I mentioned, we’re making changes to try to mitigate it. When we roll out the ability to buy capacity, that won’t affect the performance of current apps.
Good to hear a possible fix will be here already so soon. Also looking forward to the new plans, curious to see how they stack up against the dedicated plan.
Now this algorithm is live and everyone has its own capacity will guys be considering giving us an option to preload data on the page? Also controlling speed rate of upload and repeating group loading for vertical scrolling and ext vertical scrolling?
It should make sense now that everyone has a Max capacity and it will improve sales of capacity addon sales.
@josh Lately our app has been performing terrible, things almost completely freezing at times. Especially on views with many auto-binding elements.
Are you collecting any statistics on request response time / processing time? It is not a good feeling that the performance of what we pay for has decreased.
I have noticed that too, there is a significant drop in performance and page loading time for the last two weeks or more.
I have noticed that performance varies quite a bit depending on time of day too.
After 2am US east coast workflow takes less than 1 second
Afternoon/evening US east coast and workflow takes more than 15 seconds.
@josh Perhaps you can clarify something for me. I have 5 allowed apps on the Pro plan. Is each of those apps allowed 20% of my total server capacity or is my total server capacity divided by the number of active apps that I have?
For instance, I’m using 3 of my 5 allowed apps. Is 20% of my capacity allowed for each app or 33%?
Alternatively, is my server capacity split depending on the demand from each one of those apps?
The reason that I ask is that two of my apps are basically just dormant old versions of my site that I can refer back to if I really screw something up with my current design.
However, if having those 2 extra apps means that my primary active app only gets 33% of my allowed server capacity that could potentially be a big contributor to the performance issues that I’m seeing.
If that is the case, Is there anyway for me to identify certain apps as “inactive” so that they aren’t allocated any server capacity or do I just need to delete them?
I’ve been struggling to optimize all of my workflows, but if the above is true, I would probably see much larger gains by just deleting the two old apps.
Thanks for any clarifications that you can provide.
Any news about this?
We´ve been seen a more inconsistent performance lately.
Is this new algorithm working already? Or do we have to do something to update to get this improvements?
Can you provide any update, please?
Couple notes to avoid confusion:
-The new algorithm to prevent any one app from using up too much of the shared cluster’s capacity has been live for about a month now.
-What isn’t live yet is the ability to control how much capacity each app has and pay for more for apps that need more… we’re still wrapping up some technical work on this.
-This algorithm works on an app-by-app basis: each app has a total amount of capacity. If you have more than one app, they are independent of each other. (But the development + live versions of the same app do share the same capacity).
-If you’re wondering whether or not the algorithm is limiting your app, you can look at the “Logs” tab in the editor… the “Periods where the app hit its maximum capacity (%)” graph shows times where your app was up against the limits of its amount. If that graph is at zero, then the new algorithm is not having any effect on your app. (Right now we’re only showing this graph for apps on paid plans).
-Your app is also affected by overall system performance and health, which you can monitor here: http://status.bubble.is/. We’ve seen a huge improvement to our overall uptime and response time since we rolled out the new algorithm, but we occasionally still have issues where performance is affected – we’re working on squeezing them out one-by-one.