Performance of the Graph API, REST API and Web Services with SharePoint and Power Automate
When you build your flows do you consider performance? SharePoint has multiple APIs available. The Performance of the Graph API, REST API and Web Services is very different.
Graph API, SharePoint REST API and Web Services
Before I’m looking at the performance of the Graph API and the other APIs, I first want to have a look at each API.
The naming here is already a bit confusing as the Graph API is also an API following the REST protocols.
- SharePoint REST API v1
- SharePoint REST API v2/Graph API
- Web Services
SharePoint REST API v1
The SharePoint REST API v1 offers quite a few operations within endpoints that start with https://<site collection>/<site>/_api/web/…
Some of the examples of endpoint that you could use is:
The first example gets you the attachments on list items and the second one gives you the recycle bin for a site.
SharePoint REST API v2 / Graph API
All Graph API calls (and this goes a lot wider than just SharePoint), start with https://graph.microsoft.com and when you call a Graph API using the SharePoint REST API endpoint, you might find URLs like this: https://{tenant-name}.sharepoint.com/_api/v2.0/sites
So even though the Graph API and the REST API v2 are the same there are two ways of calling this API.
For more details on this please read my series on the Graph API and the Power Platform.
SharePoint Web Services
Ok, I don’t really want to go here at all, but you might every now and then come across API urls that use _vti_bin/sites
If you are then please look into the more modern alternatives mentioned in this post.
Performance considerations
I work a lot with clients who need to implement systems that put APIs under pressure. Quite often I use the following approach:
- Find the suitable steps in the SharePoint connector (The is the easiest approach, and you take advantage of any improvements Microsoft put in place!)
- If the above fails, use either the of the two SharePoint REST API options using the Send an HTTP request to SharePoint.
- If all of the above fails, use an HTTP request ( that light green premium feature that so many try to avoid) and call the Graph API.
So what are the differences in performance for each of the options?
For flows I’m going to mainly consider the situation where you get 429 error or 503 errors when things go really belly up.
We want to avoid these issues with retries and failures.
Throttling and API limitations
There are two things to consider here. Each connector has its own throttling limitation. Then Each underlying API might have its own limitations as well. I’ve created a number of experiment so that I can make a better choice for the architecture of my high performance flows.
Connector limits
For most of the connectors the connector limits are well documented. When you have a look at the connector limit for SharePoint then you will find the following table:
Ok, so there is a limitation on the amount of data the connector can receive.
Then the other limit to consider is the Throttling limits
Experiment 1 – Put the APIs to the test
So I started by building the following flow
In the above flow I’m testing the SharePoint REST API v2, SharePoint REST API v1, the listdata.svc Webservice and the Graph API without using the SharePoint connector.
Then within the Compose action just above these 4 parallel branches I’m creating an array of 5000 items.
To put the APIs under a bit of pressure I’ve also made sure that the concurrency of each of the apply to each steps is set to the maximum of 50.
And now the long wait starts…
Raw Graph API call through Premium HTTP request
After 12 minutes – The raw HTTP call to the Graph API wins the competition:
Then as I continue the wait, I’m finding that this Graph API call is an awful lot faster than the connectors. Is it maybe an idea not to use connectors but use the premium HTTP calls instead?
After 30 minute I’m still waiting for the other branches to complete.
Within our example flow we are running 15000 operations and we can run 600 operations within every 1 minute. A few quick sums, will tell us that we need 25 minutes to complete this flow. Well that isn’t the case. 1 hour later and my flow was still running.
Some careful conclusions so far
I want to be careful with my conclusions here, but looking at the performance of my flow the Raw HTTP request is a lot faster. So for high volume and high performand flows that run for a long period of time the HTTP request is possibly the way to go. Should we then skip the use of connectors? No absolutely not.
In the above example we have a very high volume of connector calls and we are hitting the connector throttling limits. Actions are permanently retrying and getting stuck in their loops.
Connectors are easier to configure, although when you use the send an http request to SharePoint action it doesn’t make much difference once you have your Azure app registration in place.
Also the HTTP action is a premium action. This is something to consider.
On top of that, I’ve ran my actions as parallel branches running these parts sequentially might also be a little bit fairer as the three branches that use the connector are all competing with each other.
Experiment 2 – Sequential vs parallel
I reduced the number a bit for my test. So my compose action will only create 500 records in an array,
Then I moved my apply to each steps sequentially. In between each part I’m putting in a delay of 2 minutes so that the connector throttling can recover a bit.
And when I’m running this flow I’m actually finding that all approaches with the APIs run between 10 and 21 seconds.
Next careful conclusions
Running parallel branches putting a single connector under a lot of stress doesn’t really help at all. However if you stay below the connector throttling limits then you will be ok. But just always putting actions in parallel will not be the best option.
Experiment 3 – Hitting the connector throttling limits
I’m going to increase the number of items to 1000. So that I’m going to hit some throttling issues. Then to show the issues of throttling I’ve removed the retry on the SharePoint action.
The 429 error shown tells us that we have issues here. We are trying to do too much in too little time.
If however I reorder my steps a bit and I’m first running the Raw Graph API call then I will see that the Raw Graph API call using the HTTP action simply works while the SharePoint equivalent one gives me throttling issue.
So the API in this case is fine, however the connector is slowing us down.
Some Thoughts
If you want stable flows that put the SharePoint connector under a lot of pressure then you might want to use the out of the HTTP request action instead
Experiment 4 – Parallel branches with lower numbers
I’m going back to the original test/ This time I’m handling 300 items in 5 branches. In my 5th branch I’ve added the get all lists and libraries action that does the same as my other steps, but in a slightly different way.
And I’m seeing the expected result:
The Raw Graph API call runs within 15 seconds, The old webservices take 10 minutes while all options through the Send an HTTP request to SharePoint are taking 5 minutes.
If I now take this back to my first experiment for a moment. In that experiment I overloaded the connector and the retries weren’t able to handle the overload. But when I have less connector action used the retry process is perfectly fine.
Conclusions
Before building your flow, you might want to consider how many items you might be processing. When your process is close to the connector limits, you might want to rely on the retry process that is there to use in Power Automate.
However when your process is likely to swamp the APIs consider queueing your requests in a alternative way. You could for example disable the retries and then keep track of all of the tailed request to that you can queue them for a retry. Be aware though that you don’t queue these requests in a SharePoint list if SharePoint is your original connector failing.
Continue Reading Pieter Veenstra’s Article on their blog
Performance of the Graph API, REST API and Web Services with SharePoint and Power Automate
When you build your flows do you consider performance? SharePoint has multiple APIs available. The Performance of the Graph API, REST API and Web Services is
Blog Syndicated with Pieter Veenstra’s Permission
More About This Author
Array
Modern Workplace26 March 2024Receive the available storage within your SharePoint Online tenant- Modern Workplace20 March 2024Options for Documenting Your Power Apps: Comments, Code, and Controls
- Modern Workplace18 March 20242 ways to duplicate SharePoint Lists to support your Power Apps
- Modern Workplace14 March 2024Update a Hyperlink Column in SharePoint with Power Automate
