A customer is using a C# app that I work on and is encountering throttling issues with SharePoint Online. The app implements the suggested throttling handling by Microsoft. The code starts with a delay of 5 seconds and makes 5 attempts. After the last attempt that had a delay of 80 seconds, the throttling error code (429) was still returned. The throttling code seemed to not work at all since it ended up just failing after 5 attempts anyway. 80 seconds seems like a very long time to delay. Any ideas what could be causing this problem or how to go about troubleshooting it?
2 Answers
Make sure that your requests have a valid useragent entry. https://docs.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online
If you are using PnP try to add entry similar to listed below into AppSettings section of Web.config:
<add key="SharePointPnPUserAgent" value="NONISV|Steve|Steve.SharePointApp/1.0" />
-
Yeah, I have the correct user agent string on every request and have read through that Microsoft post already. The throttling issue only came up with one customer so far that had many (24+) processes running on the same machine which all were accessing the same SharePoint Online account.– SteveDec 28, 2018 at 13:42
-
What about your SharePointHelathScore? Does it often exceed 8? Some time ago I worked on tenant which often got 429 or "Server is too bussy" message. We submitted an ticket to Microsoft which resulted in some change of environment under this tenant and it helped. Dec 29, 2018 at 17:57
I can verify that ExecuteQueryWithIncrementalRetry
works pretty well. I used it recently to push master page and page layout changes to 24,000 site collections. You might have some stray ExecuteQueries
in your code that are triggering the 429s. Make sure you clean all those up. Sniff the traffic to make sure there aren't any stray requests getting out. I did not need to use the user agent string.
-
Did you do that with a single thread/process? I'm wondering if my problem is occurring because of too many simultaneous threads.– SteveDec 28, 2018 at 14:02
-
I was going to ask if you were multi threading! If you think about it, multi threading defeats the whole purpose of throttling. Dec 28, 2018 at 14:28
-
I guess it depends on how Microsoft has implemented throttling. If it is based on the overall usage of a tenant account, multiple threads or processes won't really matter. If it is based on a single connection, then, yes, it would. But I would be surprised if it was per-connection throttling.– SteveDec 28, 2018 at 14:41
-
I did this using a web job and Azure queue. WebJobs scale horizontally to 32 instances by default. Now that I think about it there were lots of failures but WebJobs has built in retry logic and all but about 100 of the 24,000 sites processed fine eventually. My job took about six hours to push a total of about 100,000 documents in total. Dec 28, 2018 at 14:41
-
SharePoint cares more about volume of incoming bits from a user rather than distinguishing between connections. Dec 28, 2018 at 14:42