or, Avoiding the BLOB (and other) caches in SharePoint Online

SharePoint was designed to work best in relatively small farms on premises. A typical configuration has 2-4 web front-ends, so caching information on the web servers is a good strategy. In SharePoint Online, however, a typical farm has hundreds of web front-ends, and is shared by many tenants. As a result, the chance of finding cached content for any given tenant on any given server is greatly reduced, and server side caching is ineffective. That changes some key best practices for building SharePoint portals; in Office 365, it’s best to avoid SharePoint features that rely heavily on server-side caching.

An excellent session at Microsoft Ignite, Learn how to build a fast, responsive SharePoint portal in SharePoint Online, focused on this and other performance considerations in SharePoint Online. This article will call out key best practices to optimize portal solutions hosted in Office 365.

Navigation

The first and most popular form of navigation in SharePoint is Structured Navigation, in which sites and pages in a site collection are used to dynamically generate navigation links. This approach is easy to use and is automatically security trimmed, so users only see navigation links they are entitled to view.

Structured navigation is based on a cache called the Navigation Node Cache. SharePoint stores a cache on each web server for each recently used site collection; the cache includes permission information to provide security trimming for each user. Traditionally, it was a best practice to use this as compared with storing navigation links in a SharePoint list, for example. This is still the case on premises, where a relatively small number of web servers accessing a relatively small number of site collections makes the cache hit ratio very high.

In SharePoint Online, however, hundreds of web servers are shared by many tenants, so the cache hit ratio drops dramatically. Building the navigation nodes for a site collection that’s not in cache is very slow, since it requires iterating through all the sites and pages in the site collection. Hence, structured navigation can be very slow in SharePoint Online. Since navigation appears on every SharePoint page, this can have a significantly negative impact on the user experience.

BEST PRACTICE: Avoid using structured navigation in SharePoint Online. Managed Navigation is a better choice.

In many cases, a custom solution ends up working best. Microsoft suggests using Search, since it’s security trimmed. Most real-world solutions end up using a simpler option, such as a simple file containing the navigation HTML; this is very fast but requires skills to edit, and it offers no security trimming. Another custom option is to store navigation links in a SharePoint list; this is slower, but allows end-users to edit the list and set security on links pointing to securied areas of the portal.

Content Roll-Ups

A typical web portal home page includes summaries of content, such as news stories, featured images, calendar roll-ups, etc. SharePoint provides two main web parts for this purpose: the classic Content Query Web Part (CQWP) and the newer Content Search Web Part (CSWP). Both of these will security trim their results, so users only see items they are entitled to.

The Content Query Web Part is smart enough to cache its results, but again the cache isn’t effective in SharePoint Online where the number of web servers and tenants is so large that the needed content query is rarely in server memory. That’s not so bad if the content query gets its results from a single SharePoint list, but it can get quite slow for multi-list queries. There’s no free lunch here: the multi-list query works by finding every list and running the query again and again! This was forgivable on premises since the data was usually in cache, but it can be a real performance bottleneck in SharePoint Online.

BEST PRACTICE: Avoid using multi-list Content Query Web Parts in SharePoint online. Use the Content Search Web Part instead; this performs qute well although there is a delay in showing content changes (until the search index updates).

Keep in mind that neither CQWP or CSWP will be supported on the new modern web pages, so time invested in customizing these web parts (via XSLT and Display Templates) will be lost when moving to the new page model. Building future-proof content summaries is possible by developing custom web parts using the SharePoint Framework or, for older versions of SharePoint, the Widget pattern. These custom web parts can use REST calls to query a list or the search index without a need to recode on modern pages.

Static Content (Images, Scripts, CSS)

You may have heard about SharePoint’s BLOB cache; it may sound like a cache of monsters from a classic indy sci-fi thriller, but it’s not.

As you may know, SharePoint stores files in SQL Server as Binary Large OBjects (BLOBs) – and it takes time for web servers to read them from SQL and send them out to web browsers. The BLOB cache stores copies of frequently used files directly on web servers to avoid this overhead. Now if you’re thinking that the large, multi-tenant farms in SharePoint Online make the BLOB cache ineffective, you’d be correct.

For documents and other collaborative content, it’s worth the overhead of fetching documents from SQL Server (or SQL Server Remote BLOB Storage) – but it’s kind of a waste in the case of static files. These include images as well as other items such as JavaScript, CSS, and static HTML files stored in SharePoint libraries.

To solve this, Microsoft recommends using a Content Delivery Network to store static files. A content delivery network offers a number of performance advantages, and is even faster than the BLOB cache was on premises:

• A CDN automatically distributes files around the world, and directs users to the closest copy
• A CDN supports HTTP 2.0, which is significantly faster than the 1.1 version used by SharePoint. Notably, HTTP 1.1 requires SSL negotiation for every request; HTTP 2.0 gets a huge boost by reusing SSL connections across many requests
• A CDN is optimized for serving up static files, so there’s no overhead of accessing a database behind web servers

At the moment, this is an entirely manual operation: find a CDN, put your files there, and link to them from your SharePoint content. While this works well, it’s a lot of manual effort.

Help is on the way, however! In a blog article last month, Microsoft announced that a free public CDN is in preview for SharePoint Online. While the initial preview has some limitations, in the Ignite talk Microsoft laid out a roadmap for improving the situation over time.

• The current preview allows you to enable an option to automatically export the contents of any document library to a free, public CDN. The “public” part means that anyone who knows the URL can access the CDN content without logging in, so be sure not to set this for anything confidential! Adjusting links from the library content to the CDN is left to you and Microsoft warned it may change the URL’s in the future, so this is not production ready.
• In the future, Microsoft will automate this. They will provide a checkbox to enable the CDN publishing feature (instead of the PowerShell command required in the preview), and they will automatically adjust any links to library files to point to the CDN instead. This will eliminate most of the manual work, but will still leave your files open to any anonymous user.
• Eventually, Microsoft will introduce a private CDN that will add secured access to CDN files. This will be a nice and complete solution, in which Office 365 users can enjoy all the performance advantages of a CDN at no additional cost and with very little effort.

BEST PRACTICE: Consider moving frequently used static content to the Content Delivery Network of your choice; Microsoft Azure offers a CDN today that’s a good choice. When Microsoft releases its public and private CDN offerings for SharePoint Online, use them to optimize static file access.

Thanks for reading; I hope this posting helps you build faster and better portals in SharePoint Online!