Slow Server calls

[originally sent as an email to support but now posted here for everyone to enjoy]

Anytime I do some updates to my app and republish, the server functions take AGES to run. Like 7-20 seconds.

This has been going on for a long time now. then they go fast again, then they slow down… (I use call_s to stop the spinner showing but the server call can still take up to 20 seconds)

Its really crazy and I would love to get this sorted. Originally I thought it was because I wasn’t on the business plan so when I upgraded, I looked forward to the 3 x computing power but honestly I’m not seeing it.

I am moving as many functions into background tasks as I can. (they of course take longer to run and that’s ok and expected. I move the functions where speed doesn’t matter)

Its just the inconsistency that’s crazy. Sometimes server functions are instant… and then we have a day of slow down and slow calls.

I have the server set to always running:

Snipaste_2022-03-01_17-02-36

Is it a problem if one user doesn’t refresh and is still logged onto the old published version whilst others use the new published version?

I have scoured the forums - I imagine that a lot of the slowdown is datatable calls? but again, sometimes these are like lightning. Is there any other way of storing a variable that can be accessed by multiple users? (not just locally) I’ve changed database queries from “get” to get by ID and only search when necessary.

or…If the persistent server is still in beta, might that account for some slowdown? should I stop using it?

Help me obi-wan

As I understand it, server-side code is versioned, just like the client-side code. A user running your version N, client-side, will be connected to server-side code from the same version. As a result, you may end up with persistent server-side instances running versions N, N+1, and N-1, all as separate instances running in parallel.

Whether this is a problem depends on the nature of the differences you’ve made (from one version to the next). For example, if your version N uses the database in a particular way, that’s incompatible with the way version N+1 uses it, then there could be problems. (E.g., if N updates rows in a particular order, but N+1 depends on everyone to update them in a different order…)

1 Like

So I guess I have to kick everyone off the old version when I update. Do you know of a way to end an old version (version N) and all its background tasks etc?

Only if you’re making the kinds of changes where it would matter to your app. I make lots of incremental changes to mine, where it really isn’t going to break things. For example, changing the text or position of a label may help the user understand what’s going on, a little better, but it won’t cause the app to malfunction.

In other cases, e.g., changing a pricing structure, or ending a promotion, you may very well want to force the user to update/upgrade, so that they’re not seeing obsolete data. Even if it won’t crash the program, to use such data.

In my app (using the current IDE), the database is common across all versions. So I can put a “published” version string in the database, and in the source code. This gives the software a way to check to see whether it’s outdated. If the in-source version string does not equal the in-database version string, then the running instance of the software knows it’s not current.

Some developers find that Semantic Versioning gives them a useful way to think about – and mechanize responses to – the series of changes that they make. At the very least, it requires one to think about whether a given change is “backwards compatible” or not.

Occasionally, a single version number might not be enough. You could assign version numbers to any number of different features in your app. That way, each can change at the pace that makes sense for that feature.

1 Like

I have to say Mr P Colbert that I love this idea!

1 Like

3 posts were split to a new topic: Why does a server call from the client take longer than the server code takes to run?