Ideally, the users of an app should never need to wait for the app to sync data or react to inputs. A well-tuned AppSheet app can come close to achieving this ideal.
AppSheet apps run on a mobile device or browser. All the table data used in the app is maintained in a local copy on the device/browser. This local copy allows the app to be interactive, responsive, and run offline. The platform needs to ensure that this local data copy stays in Sync with the true source of the data which is in a cloud data provider (like Google Drive or Office365 or SQLServer).
Latency vs Throughput
When we refer to the "performance" of the app, we typically mean the responsiveness of the app as perceived by the end users of the app.
The term "latency" means time spent waiting. App responsiveness os directly related to perceived latency. our goal is to minimize latency perceived by end-users.
As you understand how AppSheet apps work, you'll see that there are different systems communicating with each other. Each communication involves the transfer of data between the systems. In this context, "latency" refers to the time a system takes to initially respond to a request. The term "throughput" refers to the amount of data that can be transferred per second. So for example, to fetch a spreadsheet from Google Drive, the overall latency is the sum of the initial latency to respond to the request and then the time taken to make the actual data transfer.
How does Sync work?
The AppSheet app cannot directly connect to the cloud data provider. Instead, it communicates to the AppSheet backend service (the "AppSheet server" in the figure below) which then acts as an intermediary to communicate with the cloud provider. This tiering is necessary for the sake of security but also has performance benefits.
Initially, let's consider the case of Sync in a read-only app. This behavior also occurs during initial launch of any app and in any app that has the Sync-On-Start option enabled.
- Read Step 1: When the app on the mobile device starts a sync, it requests data from the AppSheet Server. The AppSheet Server in turn requests data from the Cloud Provider.
- Read Step 2: Once the AppSheet Server receives the data from the Cloud Provider, it computed any virtual columns defined and then returns the data to the app on the mobile device. The app stores the data on the mobile device.
Note that in step 1, the AppSheet Server may have to fetch many tables from the same or different Cloud Providers. In step 2, all the data is sent together to the app. Later, we will discuss various optimizations that can reduce the data transferred and the time taken in these steps.
Now let's consider the case of an app that has made some data changes (to its local data copy) and is then invoking Sync. The app first sends each of the data updates in order to the AppSheet Server (steps 3 and 4 in the figure) and after that, it performs a "read-only" sync.
- Write Step 3: the app sends each of the added, updated, and deleted data rows to the AppSheet Server. If you captured photos, drawings, or signatures, they are sent along with the data rows.
- Write Step 4: When the AppSheet Server receives this information, it writes the data back to the Cloud Provider. If there are any workflow rules defined, they are also run (these will typically require that the updated rows be re-read from the Cloud Provider before executing the workflow action).
How to improve read-only Sync performance
Conceptually, there are six ways to improve Sync performance:
- Choose an efficient data provider
- Reduce the amount of data transferred during Sync
- Reduce the amount of computation (for spreadsheet formulas and virtual columns) performed during Sync
- Fetch or compute data in parallel (relevant if there are many tables in the app or many expensive virtual columns)
- Use a fast network (this is relevant for the connection between the device and the AppSheet Server)
- Make Sync happen in the background so that the user does not need to wait for them to complete.
These are explained in greater detail in this article. As an app creator, you have many options to control these aspects of Sync performance.
How to improve Sync performance when there are data updates
Data captured or updated by the app on a device needs to be sent to the cloud provider backend. This can be one of the slowest aspects of the Sync process because the changes have to be made sequentially (to ensure correctness). Conceptually, there are four ways to improve this aspect of Sync performance:
- Reduce the number of updates
- Reduce the amount of data sent with each update (eg: images captured per row)
- Reduce the amount of computation (eg: workflow rules) that must happen with each update
- Apply these changes in the background so that the user does not need to wait for them to complete.
These are explained in greater detail in this article about improving the speed of syncs with data updates. As an app creator, you have many options to control these aspects of Sync performance.
Improving app responsiveness after Sync
While we focus most of our attention on Sync, it is also useful to be aware of factors that can affect the interactivity and responsiveness of the app itself on a device. If the data set is very large, it can consume a lot of device memory which leads to slow rendering of UI. Likewise, if there are expensive format rules, there can be a lot of computation needed each time a screen is scrolled and this affects interactivity.