The new SharePoint app model provides a great framework for creating rich SharePoint solutions that run remote to the SharePoint server itself, but this move has brought in to play a new element of performance concerns that the traditional SharePoint developer has not really needed to give a great deal of thought to. In the world of server side code we could just run next to the database server along with SharePoint and the only real consideration was around querying only what we needed so we didn’t have a big impact on the SQL server – but now when we are running in a remote model, we need to give consideration to the potential impacts on performance of our applications.
There are a number of things that can be done to optimise and be smart about making remote calls in SharePoint though, and I will walk through some of them in this post. This isn’t designed to be an exhaustive list, and you may find your environment to be a little different – this is more of a “food for thought” type of post designed to get you thinking about the concepts.
Understanding the impact of API choice
Scenario 1: You need to load a large result set of data from a SharePoint list
In this scenario say you have a list that contains 4000 or so items. As a general rule of thumb you aren’t going to request all 1000 to come back at once as the loading time for that request would be enough to potentially leave your users wondering why the app is loading so slowly – so you decide to take the approach of paging through the data so you load it in small chunks. Here you will be making a single request for each chunk, and so the REST API may prove to be no more chattier than the CSOM based approach (depending on the specifics of what’s being loaded).
Scenario 2: You need to load data from multiple lists or objects
In this scenario you will find that you can batch multiple requests to load data in to a single request to SharePoint when you use the CSOM based API’s, where as the REST based approach will have you sending two requests over the wire to get to the same data. In a scenario like this you will generally see that the REST option might perform a bit worse when compared to the CSOM approach.
Query only for what you need
This might sound immediately obvious, but I felt it worth calling out here and highlighting a couple of approaches to help with this. The simple fact is that if you request more data, you will receive more data – end of story. The more data you receive, the longer it will take to come down the wire to your application. There is some great documentation on MSDN that goes over the concepts of data retrieval in the CSOM API’s (at http://msdn.microsoft.com/en-us/library/ee539350(v=office.14).aspx) which discusses the concept of using different approaches to querying such as how to do LINQ queries and filter to selecting just the properties you need, as well as the difference between the in place load and queryable load methods.
Consider where the query is going to run
This is another concept that you need to consider when creating apps – where will your query run? Let me give you a couple of examples here to outline why this is important.
Scenario 1: SharePoint hosted app
Scenario 2: Provider hosted app with on-prem SharePoint and on-prem IIS server
Scenario 3: Provider hosted app with Office365 and Azure hosted web site
The third scenario here is the same as above but swap the on-premises world to the cloud. Here you might find that the link between the Office365 data center and the Azure data center might be quicker than the link your user has between the client browser and SharePoint and/or your app. This again might lead you to want to write code in the Azure website component rather than from the client side as this could result in better performance overall.
So you can see that from the above three scenarios, having a good understanding of the impact of where your queries will run could have a big impact on the potential performance of your app.
What data will you cache?
Test, test, test!
The concepts I talk about here are just things to consider when you plan your client side based solutions, but the reality there is no single magic bullet that will improve performance in every situation, just the same as there is no magic formula to get the best performance out of SharePoint overall. So what do you need to do to ensure you are getting the results you want? Test! Load testing is something you should be doing to ensure that you are getting appropriate performance out of your environment when it is under peak load. A good load testing strategy can help identify the potential bottlenecks in your application so you know where you need to look at making optimisations if and when problems occur.
So there is my collection of points to consider when you want to look at optimising the traffic between your users and SharePoint apps. As I mentioned through the post, your millage may vary but make sure you spend the time to think through your architecture and do the appropriate testing to make sure you are making the right decisions about getting the most from your apps!