We developed and deployed a resource Management app for our organization on which we run fairly complex features (multiple bots, automations) for multiple end users. Since last week, users on Google Chrome are experiencing frequent browser crashes whereas the app is accessible on Mozilla Firefox at such times. We tried solutions that were posted on the Appsheet Forum (including clearing browser data, cookies and caches; opening the app in an incognito mode) but none seem to work. Attaching snapshot of the error messages below:
Parallelly, we also face an issue where our data source (google spreadsheet) stops to load and causes the app to crash as well. This only gets resolved if we close the spreadsheet on all systems.
These issues are turning out to be major roadblocks in our development and use of the App - we would really appreciate some help. Also grateful if anyone can direct us to the right person or team which might be able to address such issues.
Hi, Iām on a i5 with 12 gigs of RAM and an SSD. However, the problem weāre facing is across multiple PCs with everyone failing to open the app on chrome.
Thanks for sharing the fix on GChrome issue. However, since itād be hard to moderate such an issue for our dozens of end-users, is there anything we can do at the backend to solve it?
Hi @tsuji_koichi, this is how a Google Spreadsheet opens up if itās under heavy load - all features get disabled and weāre only allowed to view the data in a very HTML-esque format.
We too discovered this side of sheets recently, with our Appsheet backend.
Thanks @Steve. We are planning to move to the enterprise plan and move our data to CloudSQL. However, weāre unsure whether that will fix the Google Chrome issue. Also, can you please let me know if automations/bots run smoother on a DB backend than a GSheet one?
āSome tools might be unavailable due to heavy traffic in this fileā.
Do you have a lot of users directly accessing the GSheet file? If so, you need to try and move away from that. Build your data tools within your app, or another app.
Harshit_Goraya:
We developed and deployed a resource Management app for our organization on which we run fairly complex features (multiple bots, automations) for multiple end users. Since last week, users on Google Chrome are experiencing frequent browser crashes
You havenāt mentioned anything about the size of your data, like number of rows, etc. Did your app have slow performance before now at all, possibly from lots of virtual columns? What types of complexities do you have set up?
Hi @tsuji_koichi - we started our development with a very basic version of the application and then started adding features. We did not face any problems during the initial days, but as we ramped up, we faced such issues. Hence weāre unsure if our development (adding of bots, tasks, events) might be causing any issues.
I agree automation is always funky with Appsheet. Better to take normal debug process to see what happens with your app if we disable bot etc to sorrow the possible root cause of your problem . We do always.
Do you have a lot of users directly accessing the GSheet file? If so, you need to try and move away from that. Build your data tools within your app, or another app.
No, weāre only at 3-4 odd users using the Spreadsheet in the backend.
Marc_Dillon:
You havenāt mentioned anything about the size of your data, like number of rows, etc. Did your app have slow performance before now at all, possibly from lots of virtual columns? What types of complexities do you have set up?
Number of sheets = 20
Number of rows = ~500 in each sheet
Number of columns = ~50 for each sheet
Brings the total cells to 25000.
Downloading the Spreadsheet as a .XLSX file shows a file size of 4.9 Mb.
Weāre using very few virtual columns, only for concatenating fields for end-user view.
However, we have a lot of formulas in the āAuto-Computeā, āData Validationā and āUpdate Behaviorā sections.
The number of bots is about 20 (although they include dozens of tasks, processes, events).
Weāve observed a drop in performance (sync times, load times) as we have added more features to the app.
Thanks @tsuji_koichi. Weāll try to dig further and see if any particular bots might be the cause.
One question - We found the below information here:
Do not build an AppSheet app against a huge data set. What is āhugeā? For an AppSheet app, the compressed data size limit is 5MB or 10MB (depending on the device) for all the data in one app.
Is this also applicable against a SQL data source? Weāre unsure if 5-10MB will accommodate our requirement from the app as we scale further.
Do you have users interacting with GSheets as well as users from the App?
Are there things that could be removed from the file that are not related to AppSheet?
BTW I use around 40 sheets on Excel and the biggest one has Over 2.000 rows and filesize doesnāt pass 500KB
Do you have users interacting with GSheets as well as users from the App?
The GSheet is only used by the admin users to monitor/update data at the backend
SkrOYC:
Are there things that could be removed from the file that are not related to AppSheet?
Many sheets are not being used directly by Appsheet, but we have formulas that are fetching information from those sheets. For example, Sheet A is connected to Appsheet but a field āCountryā in that sheet is Vlooking data from a Sheet B (which is not directly linked to Appsheet)
SkrOYC:
BTW I use around 40 sheets on Excel and the biggest one has Over 2.000 rows and filesize doesnāt pass 500KB
Most of our data is strings/date which might be causing the size to go way over. Weāre also using a lot of importranges and queries to pull data from multiple sources into our backend Gsheet. However, this shouldnāt cause any problems in theory because the data size remains unaffected.
