Мain performance drivers of a Fredhopper Qserver

When it comes to performance of a Fredhopper Qserver there are many things that contribute to it.  Analyzing bottom up, we encounter the network layer, hardware or virtual machines, the operating system, the Java runtime (JDK) and the proper configuration of memory settings, all these contribute to the Fredhopper performance. In this article we focus on Fredhopper application level parameters that impact performance.

1. Choose the right data model.
   1. Reduce the amount of attributes in use for Fredhopper as much as possible, lower is faster
   2. Pick the fastest basetypes as possible. Ints are faster then floats which are faster then text, which is after then list64, set64, list, set and categories.  Assets should be used if text search is required but no facets or sorting on this attribute.
   3. Attribute values. List and set attributes can have many values, note that the more values it has the longer it  takes to calculate a facet.  Also keep in mind that incremental updates can be slow on list/set attributes with many values.
   4. More on this matter in article on Query performance drivers
2. Navigation
   1. The "tree" part of the index is the most CPU-intensive and is used for text search, facets (navigation), and sorting.  The best is to configure only the "System Manager / Navigation" attributes that you really need. Redundant attributes cause longer index times and longer query times.
   2. Watch the facet size.  Facets that display a large number of values are slower than facets that display for example, only the top 10 values (and use a more link)
   3. Number of facets per page.  The number of facets per page should be low when the user has not made any choices yet. The more refines a user does, the more (relevant) facets can be shown.
   4. Brackets, having brackets with very many (100+) values can cause slowdowns on response time
   5. Amount of triggers, each trigger needs to be evaluated real time per query, do not use too many triggers.
3. Search
   1. Control the amount of search index fields, here applies the same as navigation attributes, less will be faster
   2. Search passes, clever search passes that search only specific field might give faster and better results. For example a book author pass or article number pass.
   3. Synonyms, each synonym as well as nested synonyms slow down search, use with care! A common mistake is to make synonyms for Upper/case lower case and stemming variant, this goes automatic and can be avoided.  Another way to reduce synonym usage is to use redirects to navigation locations, this will be much faster and gives much better results for the end user.
   4. Search modifications, using too many search modifications reduces search performance. When you find that you have to create many search modifications, you should ask yourself if your data is clean, and if so if you cannot use redirects instead. Please also check if an attribute can be added to reflect the property according to which the modification is done and either sort by this attribute (for move modifications) or add the selection on this attribute to the query (for block modifications)
4. Sorting
   1. Ranking or sorting can become slow if there are many unique values in a data set. Best is to rank on attributes with many  common values and rank on a second attribute as well. Sorting on an attribute with a unique value for every item is possible, but will be slow especially on large data sets.
   2. Amount of triggers, each trigger needs to be evaluated real time per query, do not use too many triggers.
5. Campaigns
   1. The total number of campaigns is not a performance driver, what is the performance driver is the amount of campaigns returned in a single query. 
   2. The second performance driver is the amount of resulting items per campaign. Be careful not to return dozens of campaigns and every campaign having many items, this can easily become a performance bottle neck.
   3. Amount of triggers, same rules applies as for sorting and navigation triggers.
   4. The amount of campaign presentation fields shown should be as low as possible.
6. Reponse sizes
   1. Ideally keep the number of returned items per query below 50, doing more will create huge responses that will take long to generate and to transfer.
   2. Presentation fields, keep the number of presentation fields in (search) listers low, especially if you return a large number of items.

Note that 1a,b,c, 2a and 3a also influence  indexing speed. Less index attributes = faster index times!