Performance Profile sync times appear to be incorrect

Im trying to speed up a very slow app where sync times can sometimes exceed a minute. So I tested the App in various ways to try and see if there was any difference. What I found was that the Delta Sync option makes a MASSIVE difference. With sync times for an already open app being typically only about 20% of the sync time when opening an app from scratch. But thats not the issue iโ€™m reporting.

So after doing this I went into the Performance profile to find the slowest and then drill down to see what I could find. I didnโ€™t get that far. What I think Iโ€™ve found is that the manually timed syncs I did and the figures quoted by Performance Profile are VERY different. Performance Profile is reporting sync times at about 20%-25% of what they actually took.

Ignore the hour difference, that due to British Summer Time

Manually Timed Performance Profile
1333 sync via definition = 14.86s 8/14/2021 12:33:42 PM 3.088s
1337 sync via browser (new tab) = 1:02.5 8/14/2021 12:37:16 PM 22.933
1340 sync via browser (already open) = 12.74s 8/14/2021 12:40:28 PM 3.220
1341 sync via browser (already open) = 13.5s 8/14/2021 12:41:32 PM 3.071
1343 sync via phone (App closed, 4G) = 1:22.8 (about 9 secs loading) missing
1346 sync via phone (App closed, Wifi) = 36.8s (about 10 secs loading) 8/14/2021 12:47:05 PM 6.201
1348 sync via phone (App open, Wifi) = 14.4s 8/14/2021 12:48:27 PM 2.993

@praveen @Aleksi can you please copy in the best person to look into this?

0 10 290
10 REPLIES 10

Iโ€™ve also found this in Performance Profile mixed in the same list as the table sync times:

Set [Locked] to TRUE Process Table = 3.71 sec

So this is a process within a Bot. Which runs on a schedule at midnight on a Sunday. It checks for rows where [Locked]=FALSE and sets them to TRUE.

The question is, why has this shown up as part of the sync time on a user phone? Because AFAIK if its running on a schedule. That be backend stuff done by Appsheet and not the App.

Another issue in Performance Profile:

  • Customer = 15.65
    • Read table rows = 10.87
    • Compute Virtual Columns = 4.77
      • Related Documents = 1.00
      • Related Sites = 0.40

How does 1.00 + 0.40 = 4.77 ?

There are a bunch of settings in the top right of the performance analyzer that hide things so the adding everything up is often wrong due to somethings being hidden but there is still a small time difference.
Question, do you have lots of format rules?

I believe the performance sync time is basically โ€œhow long since the server got the request to the time the server is done sending the requestโ€. Anyone can correct me on that; I see a much less extreme difference like how you see it. Generally in the realm of 10-15 seconds manually and 5-8 seconds reported. We have lots of changing data on our back end outside the app so we are very cautious to put any of the time saving setting on. We canโ€™t have userโ€™s even chance seeing different information cause โ€œthereโ€™s a delay just wait a few minutesโ€ doesnโ€™t work for us. Features for Appsheet have kinda reached critical mass. I hope to see performance become the next major focus.

I think you maybe right on this though it would be helpful if someone from Appsheet could confirm. The difference in time I saw between PC, Phone Wifi and Phone 4G lead me to suspect it was internet connection speed related.

I know what you mean about the performance. Theyโ€™ve recently up the number of tables that can be read in parallel from 3 to 4. But if you go for the Enterprise licenses then this jumps to 10.

I agree. The feedback Iโ€™m getting is that syncing makes the users the app is a bit old compared to other Apps like Facebook etc that donโ€™t use syncing. I think we need a lot more granular control over the sync such as:

  • Being able to force a full sync based on some formula
  • Controlling, again by formula, what it synced. Some tables will need to be done everything whereas other you might want to just do on a monday

Well depending on how the app is set up this could 2-3x the speed or it could do literally 0. Bandwidth seemed to play a role in our testing but only when you were below a threshold. We have pretty good internet and I used the chrome inspect to throttle the internet and only when I put it down to like kb/s did we see any change but going from like 1mb to like 80mb did basically nothing.

Syncing feels like a bygone era but I think it due to the ability to use apps offlines that led to and keeps it around.

Linked to the above, the Customer table took 10.87secs just to read the table rows. Yet its a table of just 13 rows of data and 18 columns (234 cells).

To contrast that the same App has a table called Timesheet which Performance Profile claims took just 00:00:00.2078541 {โ€œRowsReadโ€:โ€œ5774โ€,โ€œColumnsReadโ€:โ€œ35โ€} (202090 cells). Or put another way itโ€™s 863 times the size of the Customer table yet took 2% of the time to sync

Iโ€™m seeing a bit of a trend. Small tables and read only tables are getting sync times way in excess of what they should. Yet some really big tables are getting suprisingly short sync times.

My first hypothesis is that for the Timesheet table sync time of 0.2 secs; we are actually seeing the Delta sync time.

Whereas with the read only tables, the issue is that even with a $10 per month core subscription you can only set the Server caching interval to be 5mins. Which means that everytime the user syncs Appsheet forces the the App to sync the entire table. Iโ€™m begining to wonder if Iโ€™d be better off setting these tables to editable and relying on Delta Sync to reduce the sync times as they never change.

Incindentally the Customer table detailed almost never changes. Well one record has been modified in the last 12months. The table settings (updates/add/delete/readonly) are controlled by a formula. For the sync in question, this table woud have been read only. So presumably is being force to be read entirely rather than using delta sync.

Very interesting thought on setting delta sync. Seems counterintuitive. Read only table should not have to be processed on a sync, except the initial app sync.

It used to be you could set it to more than 5min on the $10 pm licenses. Then Appsheet changed it so you could only pick 5mins. I remember because it caused a lot of my apps that were using > 5min to flag up as using the wrong licenses

The data in the table may be read-only by the app, but the data may change at the data source. Changes at the data source would then need to be synced to the app.

I donโ€™t think the data changing is the big issue. Its the fact that most people donโ€™t sync the app < 5mins, on average. Therefore Appsheet will always send the the entire table.

Top Labels in this Space