My App sync is super SLOW and I am only in development fase

Hi Guys,

I am in the process of completing my app which is connected to a data to MySql on AWS. But the syncs are super slow and check out the Performance Analyzer for AppointmentApp-1361161 and Sync Durations are over 86 sec. From looking at it I am not able to determine cause of the delay. Help much appreciated have to deploy this week.



First thing to ask is do you have a lot of Virtual Columns in your app tables? These are recomputed every time you sync and if you have any table query type expressions (SELECT(), FILTER(), MAXROW(),etc), these Virtual Columns are slowed by those computations and will get slower over time as the tables grow in number of rows.

Second, could you drill into the Performance Analyzer results and show a screen shot of them? This might allow us to help focus on the problem area better.

1 Like

Hi John,

Here are the screen shots. I think I might have found the culprit.

1 Like

The sample Sync you are showing took 1 minute and 38 seconds. The table listed at the bottom of the Performance Analyzer data image (“v_ProvinciasMunicipiosBarrios”) is showing to have taken 1 minutes and 36 seconds of that sync time. So you will want to drill into that tables performance data .

Turning on server caching will help some but the sync’s will still be slow.

I notice in the Performance Analyzer, your first table “cliente” is showing over 837,000 rows. And that is just the client list. I imagine your other tables are of similar scale?

Just the shear size of these tables will make the sync slow.

You definitely do not want to have this much data (if the row counts are as indicated) in a mobile application. Are you taking measures to scale down the size of the data for use within a mobile app?

1 Like

Hi John,

Thanks for the pointers that table data was incorrect. Fixed it and the sync times have improved dramatically for better.

Regarding virtual columns how does one work arround them or avoid them?
How many is to many?

Thanks for the help.

1 Like

There are times when you cannot avoid them such as for things that are re-calculated each time new data is retrieved AND you want the displayed value updated automatically.

You would want to avoid them for things that are computed or displayed but do not change frequently.

For instance, say for display purposes I want to show some Customer information on my Order record that requires a complicated SELECT() statement in order to retrieve it. I might think that I don’t need to store a duplicate so I place it in a Virtual Column. Well, on a sync, that Virtual Column will be re-calculated (SELECT() re-executed) for every Order row every time Sync runs. If I have thousands of order rows, this will slow down the Sync.

Realizing that this value will only ever change when the Customer on the Order changes (probably never), it then makes sense to create an extra column and duplicate this value on the Order record. I can place the SELECT() in the App Formula for the column and then it will only execute when the Customer is set or changed - saving all that extra Sync time.

This depends on the complexity of the Virtual Columns and is mostly going to be dictated by the performance of the Sync and your judgement of what is too slow.


Great advice John. James, if you haven’t had a chance to see these yet, we have various documentation on approaches to take when trying to reduce sync speed. It might be helpful as you grow your apps and user base:

Scaling data:

Data updates & sync speed:

Speed of sync - core concepts:

I hope this helps.