Fredhopper Data Configuration Best Practices
These are best practices to follow when configuring the data integration with your FAS instance.
Last updated
These are best practices to follow when configuring the data integration with your FAS instance.
Last updated
When configuring your integration with Fredhopper, it's important to optimise the data integration to maintain performance. For each data parameter listed, there is a recommend optimal setting or limit, and if applicable an acceptable upper limit. Ignoring a recommendation won't individually cause an issue, but when combined with other recommendations being exceeded, it may lead to performance issues. Where there is an optimal and acceptable recommendation, consider the acceptable as a maximum limit.
This refers to the total number of primary and variant items, per universe.
It's important to practice good data hygiene with your catalog in Fredhopper. The number of items in the catalog will directly affect the performance of search and recommendations.
Recommendations
Limit the number of items in your catalog where possible.
Optimal limit: 1 million items
Acceptable limit: 2 million items
The number of attributes per item will impact performance.
List and set attributes can have many values; the more values present the longer it will take to calculate a facet. Also keep in mind that incremental updates can be slow on list/set attributes with many values.
Recommendations
Pick the fastest possible.
Ints are faster than floats which are faster than text, which is faster than list64, set64, list, set and categories.
Assets should be used if text search is required but no facets or sorting is needed on the attribute.
Use list64 / set64 type when an attribute has less than 64 distinct values.
The Navigation index gives control over which attributes can be used for sorting (e.g. in rankings, modifications, campaigns), faceting, filtering (query criteria like stock>0, color<{black}), or for some types of triggers (e.g. value distribution).
If attributes are not needed for any of the above, deactivate them to improve re-index times and query performance.
This is one of the most important parameters affecting performance, and should always be minimized.
Recommendations
Remove all unused attributes from the navigation index.
Manage the number of attributes used for sorting, faceting and filtering in search to reduce re-index times and improve query response times.
This is configured per universe / locale.
Recommendations
Limit the number of attributes to improve performance.
Optimal limit: 25 index attributres per universe/locale
Acceptable limit: 50 index attributres per universe/locale
The frequency of incremental updates has an impact on query response times because on every incremental update the navigation cache is cleared.
The lifetime of the navigation cache must be set to a value higher than the interval between incremental updates, to avoid unrequired clearing of the cache.
This is done in system.xml, with an entry under node /com/fredhopper/service/NavigationCache:
Value 5, which is the system default, should be changed to a value higher than the maximum interval between two incremental updates.
Recommendations
Set the incremental update frequency at most every 30 minutes. Navigation cache must be set to a higher value than the increment update frequency.