Tune product grouping

Tune 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:

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.
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 dress, grouping is done on both search results and facets' values.
Table 1.
1. The Color facet shows that there are 14 matches with color Red.

2. When selecting the Color Red facet value, there would be 14 products returned in the search results.

When group.facet is set to false, and a search is submitted for dress, grouping is done on search results only, but not facets' values.
Table 2.
1. The Color facet shows that there are 70 matches with color Red, because the count accounting for SKUs too.

2. But when selecting the Color Red facet value, there would be still be 14 products returned in the search results, because the product grouping is applied to the search result.

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:

Use the default sequencing function on category pages:

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.
Alternatively, consider disabling the sequencing provider com.ibm.commerce.search.internal.expression.provider.SearchProductSequencingExpressionProvider, and apply sorting on a single value field. See Disable search expression providers and result filters in the search configuration file (wc-search.xml).
Set the UseValueSourceFunctionForSortingsearch configuration to false in the Search EAR wc-component.xml file. This configuration will allow you to use the Solr native sort function instead of the default sort function in order to provide better performance. See Search properties in the component configuration file (wc-component.xml).

Expanded category navigation on top category pages.

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.
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:

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:

In extreme cases you may find combinations of large result sets. This can occur when a product has a large number of SKUs, a large page size, and many facets returned by the search query. If such cases occur, consider making two search requests. One will populate the facet widget, and the other will populate the product search result set. Each of the search requests can be optimized. Optimizing the facet search request would require that group facet be set to true, and row count set to 0. The product search request can be optimized by setting group facet to false.

Related concepts
Product grouping

1. The Color facet shows that there are 14 matches with color Red.
2. When selecting the Color Red facet value, there would be 14 products returned in the search results.

1. The Color facet shows that there are 70 matches with color Red, because the count accounting for SKUs too.
2. But when selecting the Color Red facet value, there would be still be 14 products returned in the search results, because the product grouping is applied to the search result.