Appsheet loading time increasing with records - google sheets with security filter

[Nelson_Sum]

I have around one table contain 2500 services record. My users can view the specific record base on the security filter (by usermail when they create theirself order) . I feel that the speed of start up of the appsheet getting slower, is there any better way to improve the load time?

[LeventK]

@Nelson_Sum
Have you checked the Perfomance Profile under Manage >> Monitor and take a look at what step app sync time is increasing?

[Nelson_Sum]

Thanks for your advise.

There’s app sync process, some user take around 30 second. the detail show DegreeOfParallelism, not sure what process it is exactly refer to. but add row or edit row just within few seconds.

[LeventK]

@Nelson_Sum
There should be some details under that regarding which table, virtual column calculations etc.

[Nelson_Sum]

Great thanks, i managed to figure out the reason of long loading time.

However, i can’t remove those virtual column which is automatically generated again after i delete it in columns.

I build several trigger reports refer to the orders period, but i don’t required user to refer it while loading the apps, all reports will send via email

[pravse]

Hi Nelson, if you have related tables, then there will be virtual columns auto-created to compute the “reverse references”. Thar said, the perf profiler could be confusing because the actual execution is not always sequential.
The reason for long loading time is almost always the latency of actual loading of data from the cloud source. Sometimes, this time is hidden under the time taken to evaluate a virtual column (dependent on fetching all the rows from one other table).

[Nelson_Sum]

Noted, so that to improve the loading time, can i say it would help if minimize the record rows of each related tables? or simplify the structure of tables help more?

[pravse]

In general, each table has a fixed latency (time spent waiting for Google Drive or whatever source to respond) and then a variable overhead depending on the number of rows. Virtual columns also get computed, but this is significant only for expensive expressions, not for simple REF_ROWS expressions. For small tables, the fixed latency dominates the cost. If you have an app with lots of little tables, it will still take a long time to sync because of the fixed latency. So my general advice is: (a) reduce the number of tables needed by the app … this usually means, have less functionality in each app and split it out into multiple apps if needed, (b) reduce the number of rows per table — ideally using security filters, © check any custom virtual columns that have expensive expressions — anything with a SELECT inside it, for example.

[Nelson_Sum]

Noted the mechanism behind now.
What if i split into multiple apps, would the charges increased?
If i created another app doing the reporting only, then the basic app keep data input only.
I have a group of users in data input apps, then few of them will access another apps for reporting only. Will it charges twice on the same user while two apps?

[Aleksi]

@Nelson_Sum If you have all apps in one account, it doesn’t have any affect. You can have as many apps as you need in one account.