Too Many Requests Error / Throttling Limits

[Sarah_Keown]

Hi, we have been having issues with a specific app error “Too many Requests”. Below is an example of the full error descitpion.

We reached out to appsheet support who informed us that it is due to Microsoft Storage account throttling limits, and forwarded the below article to us.
Request limits and throttling - Azure Resource Manager | Microsoft Docs

These apps have been in use for months, some even up to a year onwards, and it seems as though this past week these errors have been received. They are spontaneously appearing to different users, on different apps there is no recognisable pattern.

Our account has 103 users.

Is anyone else experiencing these issues?

[Koichi_Tsuji]

I strongly suggest to move your backend to Google from excel online which is not a cloud friendly. Such a thing could happen with Microsoft.

[Steve]

Sarah_Keown:

These apps have been in use for months, some even up to a year onwards, and it seems as though this past week these errors have been received.

That suggests you’ve been adding more users, or users are using the apps more, or your data set has grown, or a combination of these.

Sarah_Keown:

They are spontaneously appearing to different users, on different apps there is no recognisable pattern.

It comes down to how many users are using the app at about the same time. It’s not a bug in your app; it’s a limitation with Microsoft (as the error tells you).

tsuji_koichi:

I strongly suggest to move your backend to Google from excel online

I agree.

[WillowMobileSys]

Steve:

tsuji_koichi:

I strongly suggest to move your backend to Google from excel online

I agree.

Gentlemen. This question came up in another thread. Google has throttling limits as well. Does AppSheet provide increased limits in some way?

[WillowMobileSys]

Steve:

Sarah_Keown:

They are spontaneously appearing to different users, on different apps there is no recognisable pattern.

It comes down to how many users are using the app at about the same time. It’s not a bug in your app; it’s a limitation with Microsoft (as the error tells you).

@Sarah_Keown As @Steve points out this is not a bug in the app. And you should take this a compliment. It means your app is being well received and utilized.

---

Before taking intrusive steps to change the backend, you might look at the data tables to see if any data can be purged and/or archived.

It might be that the data is NOT used but needs to kept - candidate for archiving which, for now, could be as simple as copying the sheet data into another file and then deleting the unused data in the app.

If the old data is simply NOT needed at all - purge it.

These steps might reduce the data size and get you by until you can devise a plan to handle the increased growth in the app.

[Sarah_Keown]

Would it help to use security filters to archive older data that is no longer in need of processing, or would we need to remove the data from our app data entirely?

[MarkWAppDevelop]

I doubt it, but its worth a try…

the best approach short term is as indicated above to archive off the older data and delete it from the operational data system.

you could make a copy of the app(s) and direct them to the archive, or use GDS (Google Data Studio) to make reports on the archived data.

Another thing to look at is deleting unused columns and rows, and worksheets in the workbook.

I am not sure if excel will add new records at the end of the spreadsheet if needed, so please check that first with a test app!

I know that Googlesheet does this since that is the platform I use for most entry to mid-level apps.

For larger Data sets, you would look at moving it to a cloud based SQL-Database, which removes these kind of restrictions (the size they can handle is far greater!)

Hope this helps!

[WillowMobileSys]

Sarah_Keown:

Would it help to use security filters to archive older data that is no longer in need of processing, or would we need to remove the data from our app data entirely?

Yes, I believe it will. One of the concerns for the “too many requests” are Virtual Columns. These are recalculated on the server and I believe that recalculation takes into account the number of rows allowed by the security filter(s). Reducing the number of rows should reduce the number of updates by Virtual Column and therefore reduce the number of update requests made to the datasource sheet.

On the other hand, how AppSheet servers manage the updates is a bit of a black box. But when I think about multi-tenant apps, we certainly would not want the Virtual column re-calcs to cross client datasets and those are decided by Security Filters. This is why I think a Security Filter could also help with the throttling limits.

[SkrOYC]

WillowMobileSystems:

Reducing the number of rows should reduce the number of updates by Virtual Column and therefore reduce the number of update requests made to the datasource sheet.

It’s true.
I changed a table were almost all the columns were AppFormulas and there was no reason for it for InitialValues and made them uneditable. That saved my AppSheet app from calculating them.
In general, since you have so many users, it’s a good point to check if there are AppFormulas/VC/OldRows that could be left out of the sync process