> For the complete documentation index, see [llms.txt](https://fredhopper.gitbook.io/product-discovery/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fredhopper.gitbook.io/product-discovery/sending-and-managing-product-data/what-is-the-items-api/best-practice/fredhopper-data-configuration-best-practices.md).

# Fredhopper Data Configuration Best Practice

These are best practices to follow when configuring the data integration with your FAS instance.

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.

### Catalog Items

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.

{% hint style="success" %}

* **Optimal limit**: 1 million items
* **Acceptable limit**: 2 million items
  {% endhint %}

### Item Attributes

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**

{% hint style="success" %}
Pick the fastest [basetypes](https://github.com/Attraqt/product-discovery-documentation/blob/main/new-docs/sending-and-managing-data/sending-product-data/item-catalog-management/how-to-work-with-items/item-schema/attributes.md#available-types) 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.
{% endhint %}

{% hint style="success" %}
Use `list64` / `set64` type when an attribute has less than 64 distinct values.
{% endhint %}

{% hint style="info" %}
Consult the [guide on choosing base types](/product-discovery/sending-and-managing-product-data/what-is-the-items-api/working-with-items/item-schema/attributes.md#type-decision-tree) for more information.
{% endhint %}

### Navigation Index Attributes

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.

{% hint style="warning" %}
This is one of the most important parameters affecting performance, and should always be minimized.
{% endhint %}

**Recommendations**

{% hint style="success" %}
Remove all unused attributes from the navigation index.
{% endhint %}

{% hint style="info" %}
The list of attributes in the navigation index, and their current usage in merchandising rules can be seen in the System > Navigation > Navigation index page of the merchandising studio.
{% endhint %}

### Search Index Attributes

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.

{% hint style="success" %}
**Optimal limit**: 25 index attributres per universe/locale

**Acceptable limit**: 50 index attributres per universe/locale
{% endhint %}

### Incremental Updates

The frequency of incremental updates has an impact on query response times because on *every incremental update* the navigation cache is cleared.

{% hint style="warning" %}
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.
{% endhint %}

This is done in `system.xml`, with an entry under node `/com/fredhopper/service/NavigationCache`:

```
<entry key="result-lifetime" value="5"/>
```

Value 5, which is the system default, should be changed to a value higher than the maximum interval between two incremental updates.

**Recommendations**

{% hint style="success" %}
Set the incremental update frequency at *most* every 30 minutes.\
Navigation cache *must* be set to a higher value than the increment update frequency.
{% endhint %}