Compartilhar via

New group cache for the Content Search Web Part

  • Artigo

Authors:

  • Helge Grenager Solheim is a principal program manager lead in the FAST team.
  • Alex Pope is a senior software developer in the FAST team.
  • Omar Faruk is a software developer in test II in the FAST team.

Summary

A new cache mechanism is available for page editors using the Content Search Web Part (CSWP) in Intranet scenarios in SharePoint Online. By configuring a group to “run the query as”, the result of the CSWP query will be cached by the system and shared amongst all users of that group. This results in quicker page load times and improved user satisfaction.

Introduction

In October 2013, we announced the availability of the Content Search Web Part (CSWP) and Cross-Site Collection Publishing in SharePoint Online. Today we’re announcing a new configurable group cache mechanism to accompany the CSWP. This is the response to seeing multiple scenarios where all users get the same results for queries, and thus, when many users access such a search-driven page at the same time it is not necessary to evaluate the query once per user.

Content Search Web Part (CSWP) fundamentals

The CSWP is a Web Part that you can put on any SharePoint page and it displays any content from the SharePoint search index based on a search query. The query results are rendered using display templates (HTML5/JavaScript/CSS), and a number of display templates ship out of the box for your use.

So, basically, to use the CSWP, you just specify what to show using a query and how to show it by selecting the display templates to use.

Group cache

The group cache is a way to get great page load performance of search driven intranet pages when using the CSWP. It

      • Speeds up your search driven intranet pages.
      • Makes complex queries fast.
      • Decreases page load times.

The group cache uses your existing security groups. Simply select a group that has access to your content and all users in that group will use the cache and share results. The system will make sure to refresh the cache with fresh results every 15 minutes, so you will still get the benefit of search-driven results and constant updates to your web pages.

 

How to use the new group cache for the CSWP

The group cache is configured when editing the CSWP, more specifically inside the SETTINGS tab of the query builder as shown in the figure below:

As can be seen, there is a new setting called “Caching” where it is possible to select a group to use for caching.

Group cache scenarios

The group cache is ideal for:

      • Home pages and starting pages that a lot of users have as starting points in their browsing sessions.
      • Peak load scenarios where single pages are opened a lot during short time intervals or during business hours.
      • High traffic category pages that work as starting points for more detailed pages.
      • Complex queries that are slower to execute and would benefit users if cached.

For all the scenarios above, the group cache will be most useful with 10 or more page loads within a 15 minute time frame.

The group cache should not be used for the following scenarios:

      • Few users and little usage traffic.
      • Low traffic pages that are not used a lot.
      • Personalized queries that should display different content for different users.
      • Granular security scenarios where documents are not shared amongst large or well-defined groups.

Consider the following scenario for Contoso. On their Intranet front page they have some featured news (A), some more news (B), a list of the most popular documents in the company the last 14 days (C) and recently edited documents by the current user (D). That makes up four CSWPs in the page shown below:

Now, of these four searches, two should be cached:

  1. A + B: The featured news and regular news are the same for all users. Given a high amount of concurrent page usage, users will benefit from these results often coming from a faster cache.

  2. D: The documents the current user has modified in “My stuff” naturally cannot be cached amongst different users, even if all users had access to all documents, because the query is not the same for all users.

  3. C: The popular documents in the company can potentially be cached, but unless a significant portion of documents are available to everyone it is probably better to leave this un-cached so that e.g. users in the HR department can also see popular documents restricted to that department and likewise for users in other departments.

Limitations and constraints

It is only possible to use Active Directory groups. SharePoint groups are not supported. In addition, no content with deny Access Control Entries (ACEs) in the Access Control List (ACL) will be shown when using the group cache. The technical reason for not showing content with deny ACEs in the ACL is because it decreases performance. To safely handle ACLs with deny ACEs, the system would need to post-trim every search results before displaying it on the page. This would make every request more expensive to evaluate. Instead of doing this, we have analyzed Microsoft’s own intranet content and found that very few documents actually have this kind of permission settings. Therefore, ignoring all such documents is believed to be an acceptable trade-off for this group cache.

Due to implementation details, only content crawled or re-crawled after February 24th 2014 will show up in search results using the group cache. If you find that content is missing, you should re-index your document library or list.

The output cache is compatible with the group cache. However, query results are not cached inside the output cache. Instead, all CSWP queries will be made asynchronous when using the output cache.

Availability

Everyone that have access to using the CSWP in SPO will have access to the group cache. The CSWP is available in the Office 365 Enterprise E3 and Office 365 Enterprise E4 plans (as well as G3/G4, A3/A4 and E3 for non-profit).

As of the publication date, the CSWP is only available for private site collections. The group cache only applies to private site collections.

FAQ

When will this group cache be available for SharePoint on-premises?

  • We do not have an exact date, but are working on making it available.

Does the group cache work with async queries?

  • Yes. The group cache can be used both with sync and async mode CSWP queries.

Does the group cache work for other search-driven web parts?

  • The group cache can be used for the following search-driven web parts: Content Search, Catalog-Item Reuse, Items Matching a Tag, Pages, Pictures, Popular Items, Recently Changed Items, Recommended Items, Videos, Web Pages, and Wiki pages.

Does the group cache work with the search results web part?

  • No, the group cache is not enabled for the search results web part.

Can I use this group cache through the REST API or the Client-side OM (CSOM)?

  • Yes. To do that, send a claim for the group in question as a property named RestrictToGroups with the query.

  • A REST POST query looks like this for the Everyone group. Replace the StrVal part to use another group:

{

'__metadata':{'type':'Microsoft.Office.Server.Search.REST.SearchRequest'},

'Querytext':'sharepoint',

'Properties' : {

     "results": [

                 {

                     "Name": "RestrictToGroups",

                     "Value": {

                                   "StrVal": "c:0(.s|true",

                                   "QueryPropertyValueTypeIndex": 1

                              }

                 }

                ]

               }

}

 

 

References

Comments

  • Anonymous
    October 02, 2014
    Hi,

    In March 2014 we announced a new group cache for the Content Search Web Part (CSWP) in SharePoint