SOLVED

Maximum rate of provisioing Sharepoint sites

Microsoft

 

We have a scenario where a Azure based webjob is using Grpah API to create large number of Sharepoint online sites . What is the limit on the rate of provisioning Sharepoint online sites ? Where is such imformation published? How can such limits be relaxed for a deployment phase of the project that requires such large number of sharepoint online sites to be created ?

7 Replies

@Lalit Mohan  there are no specific numbers on this as it depends on many things, like if you are provisioning a complex site or not.

If you are using PnP provisioning, then you are already covered by the build-in exponential back-off approach (recommended by Microsoft) to wait if you reach the throttling limits, but if not, you may need to implement that approach yourself.

In short, there is no way to fully bypass the API limits as they are there to ensure performance is not compromised. But there are a few things that can be done, like using different user accounts as throttling will first be applied at the user account level.

Planning will be key :) And if possible, start earlier, just in case :)

 

 

thanks Jeol, what are the API limit numbers ? Also can point to more detailed documentation on this. thanks in advance. Regards
best response confirmed by Lalit Mohan (Microsoft)
Solution

@Lalit Mohan I believe the API limits are not available publicly.

Regarding PnP provisioning (I think this was the second part of you reply, apologies if not), you can use this as a starting point:

https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/introducing-the-pnp-provisioning-e...

 

I have worked in some projects with similar challenges and there is generally some work that can be done in advance to minimize the load on the APIs when the bulk of the work needs to take place.

For example, create blank sites in advance, provision blank lists/libraries, provision some custom fields/content types, etc...

thanks that is helpful and much appreciated, share any example code if it is shareable ...

@Lalit Mohan I don't have anything particularly useful worth sharing. All the main features that I took advantage from are available from PnP provisioning and that project is well documented to help you get started.

So, @Joel Rodrigues, what you're saying is:

 

  1. There is no hard and fast daily limit for how many site collections can be provisioned
  2. The provisioning limitation is more of a throttling of API calls, which can vary based on numerous factors in and out of our control
  3. MSFT recommends using PnP provisioning as a best practice to handle exponential back-off based on detected throttling.

Did I understand all of that correctly?

@jbhoward 

 

1 - no limit that I am aware in numbers of site collections that could be created per day

2 - I have been in multiple projects were we hit throttling and that is what ultimately limited us

3 - I don't think MS recommends PnP provisioning as it's a 3rd party open-source library and they would not formally recommend it, but there are lot's of references in MS docs so make your own conclusions :) And it's the tool adopted and maintained by the dev community so you can't go wrong. PnP provisioning already has back-off built-in as part of PnP Framework (previously PnPSitesCore) so you generally don't need to worry about that 

1 best response

Accepted Solutions
best response confirmed by Lalit Mohan (Microsoft)
Solution

@Lalit Mohan I believe the API limits are not available publicly.

Regarding PnP provisioning (I think this was the second part of you reply, apologies if not), you can use this as a starting point:

https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/introducing-the-pnp-provisioning-e...

 

I have worked in some projects with similar challenges and there is generally some work that can be done in advance to minimize the load on the APIs when the bulk of the work needs to take place.

For example, create blank sites in advance, provision blank lists/libraries, provision some custom fields/content types, etc...

View solution in original post