Tuning product grouping

The product grouping feature is based on the Solr field collapsing and result grouping query feature. There might be performance impacts when you enable product grouping. Consider the factors that influence performance impacts and how to design and tune to minimize the impact. It is recommended that you assess the business requirements for the affected store pages, as some of the configurations might change the search results being returned.

When product grouping is enabled, and to return the most relevant visual content and accurate facet values, the search scope is increased to use the ALL search type for catalog entries, including SKUs. Although the final search result displayed in the storefront filters out SKUs, some of the preceding processes are still run on the entire result set, which includes SKUs.

The performance impact is typically caused by working with large result sets, caused by increasing the search scope to include SKUs. The following list describes the different factors that contribute to the extra performance impact when you work with larger result sets. Alternative options are presented that can help improve product grouping performance.

Procedure

Product level facet count and Item level facet count:
1. SKUs are accounted for when facet count is displayed, since SKUs are included in the search scope. However, there is a group.facet parameter, enabled by default, which can be set to do post query operation to calculate the facet counts at the product level. This operation has a performance impact that is proportional to the number of facets and the size of the result set. This is the default behavior.
2. Alternatively, override the group.facet value in the search configuration file (wc-search.xml) and set it to false.
  For example:
  - When group.facet is set to true, and a search is submitted for red dress, the following screen capture shows the facet count that is applied:
  - In contrast, when group.facet is set to false, and a search is submitted for red dress, the facet count also represents the matching items, even though the search result displays products only:
3. When a slow response page load time is observed with group.facet set to true, consider setting the value to false. The site administrator must decide on either displaying the facet count at the item level, or alternatively omitting facet count values.
  
  For example:
Using the default sequencing function on category pages:
1. The default sequencing function applies a sorting logic on a multivalued field. A sequencing function is created to do so, as Solr does not support sorting on multivalued fields. The larger the result set, the more expensive the sorting operation becomes.
2. Alternatively, consider disabling the sequencing function, and apply sorting on a single value field.
Expanded category navigation on top category pages.
1. When expanded category navigation is enabled, the top category pages might return a large result set, which might imply a larger number of facets, and expensive sequencing operations.
2. Alternatively, consider not displaying product listing widgets on top category pages that might return high large result set, and have only product listing widgets on leaf category pages.
  
  For example, when expanded category navigation is enabled, and a top category page such as Apparel is selected, all of the products under the Apparel department are returned:
3. When a slow response page load time is observed on top category pages with deep search is enabled, consider disabling the product listing widget on any other category page other than the leaf category. Instead of displaying products, consider including links on top category pages that direct to leaf categories instead of displaying products.
  
  For example: