Solved: Concerns about Using an AppSheet Application for 4... - Page 2

11198 · 08-07-2024 02:04 AM

We are currently subscribed to Google Workspace, and our organization has 400 accounts. As a result, all employees have been assigned Core licenses.

We are planning to create an AppSheet application that can be used by all 400 employees, with Google Sheets as the database. For now, let's set aside concerns related to data volume and user management (such as adding or removing users).

I would like to know if there are any potential issues that could arise when using a single AppSheet application with 400 users. In particular, I am concerned about the risk of the app crashing or becoming unresponsive due to a large number of users accessing it simultaneously.

Additionally, if there are issues, would upgrading from Core to an Enterprise license help resolve them?

Since I need to explain this to my colleagues, I would appreciate it if you could provide details on whether or not issues are likely to occur, along with an explanation of how AppSheet handles such situations.

Thank you in advance for your assistance.

Rich_E

I have a detailed explanation around concurrency (number of simultaneous users) below. In general with the 400 users you will need to know how many of the users will be interacting with the app at any given moment. Realistically if your app approaches 50 concurrent users and is connected to a Google Sheet, then you need to perform the following analysis to make sure users will not run into issues. When the limits are reached, users will receive timeout error messages in their app.

The concurrency limits are based on the backend datasource used. Below are the limits to Sheets, AppSheet Databases and other datasources.

Google Sheets
Google Sheets can handle 300 API calls per minute. An API call is what AppSheet uses to read/update from any particular table in the same sheet.

For simplicity purposes imagine an app with 3 tables, this app can handle 100 users that can open and sync the app per minute (300 divided by 3). If the app has 6 tables then you decrease the number of users to 50 users/min (300 divided 6). Note this does not consider any updates, adds or deletes which add additional API call requirements and reduce concurrency.

Note: you can split your tables into their own separate spreadsheets, each with their own 300 API call limit. We even support data partitioning as an advanced option to further expand this limit. https://support.google.com/appsheet/answer/10105383?hl=en

AppSheet Databases (ASDB)
An AppSheet databases can handle 100 transactions per second (6000 tx per minute). The same rules for Google Sheets apply above. So for an apples to apples comparison:
3 Tables: 2000 users/min
6 Tables: 1000 users/min

Just like with sheets you can split and partition tables as well to increase the concurrency limit.

Other Datasources
The limits when using other datasources will depend on these services. Generally the app itself will not be the bottleneck for concurrency, it will be the number of connections the datasource can handle.

Read only tables
Read only tables are cached at 5min, 30min, 1hr, or 1day intervals (default is 5 mins). Read only tables would only consume one call/tx for all users in that time period. So lets say you had 1 read only table in the above examples. Then your concurrency limits would effectively look like the following as there would be one less table needed to be accessed with every sync:

Sheets (3 tables): 150 users/min
Sheets (6 tables): 60 users/min
ASDB (3 tables): 3000 users/min
ASDB (6 tables): 1200 users/min

View solution in original post

Concerns about Using an AppSheet Application for 400 Users