Indeed, publishing Part 3 in this series is too late but considering the growing demand for Office 365 I think this is still helpful to the SP community.
Well, before diving into the solution, first have a look at the potential problems with Office 365 performance. Consider following scenarios where invoking the O365 APIs is required from client side (JS in most of the cases):
- Display latest news/events on the landing page of Portal having >50K users. Querying REST APIs every time sounds very expensive operation.
- Querying Querying Terms from taxonomy is very common requirement. Consider an Organization with 30+ departments across different geographies. Every country’s department has a local managed navigation. In this case 1000s of terms would be created in the managed metadata navigation. Getting 50 terms only (to show a local navigation of an “IT” department of a country) from 1000s of managed navigation terms in the taxonomy would be a very expensive operation. Querying terms from 3rd level (or deeper than this) in the terms hierarchy can bring down the performance as it requires invoking taxonomy APIs more than once.
- Different pages in the portal require User profile properties to display conditional UI elements from JS. Invoking User profile APIs on every page will not be a right approach.
- Query list items to personalize the Page content if user has set up personalization settings is a SP list.
- Fetch application configuration settings items stored in the Lists. This is usually required in all the web applications/portals.
There are several such scenarios in which querying same Office 365 content on various pages is required. Above are very few of those. Numerous serialization and deserialization operations take place in the background when Office 365 API is invoked even once and these operations badly affect the performance. Caching solution becomes the urgency to store static and frequently used content.
Client side session storage or local file storage can resolve the performance problems to certain extent but they have their limitations and disadvantages such as data concurrency, expiration policy etc.
Yes, distributed caching is the saviour to resolve performance and data concurrency problems.