A Solr /select query has an optional &rows parameter that tells the Solr responseHandler how many documents to include in the response. The default value is 10 documents. For a given query, response time goes up with the number of rows requested.
For instance, we ran a single-keyword query against a collection of 13,500,000 retail products. The QTime varied with &rows, even though the numFound (number of matches) did not. (QTime is milliseconds that Solr spent processing the query.)
|72441||10 (Solr default)||156 ms|
Many factors influence these timings (such as caching), but you can see that minimizing the &rows setting is likely to be a Best Practice.
Sitecore &rows Settings
By default, Sitecore sends /select and /suggest queries to Solr with the &rows parameter set to 1000000, and in some cases, to 100000000. These settings places enormous stress on Solr, sometimes maximizing CPU and JVM usage, because Solr allocates enough memory to hold a million documents before processing each query. Since Sitecore can issue hundreds of these queries in a few seconds, the memory load can exceed Solr’s ability to cope.
SearchStax recommends lowering the default setting:
- In your Sitecore installation, navigate to
<setting name="ContentSearch.SearchMaxResults" value="1000000" />.
- Change the value to “1000” unless you really do need more than a thousand documents.
- Save the file and restart Sitecore.
You should see the change reflected in the /select requests recorded in your Load Balancer log files.
For further information, consult this Sitecore Knowledge Base article: https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0671173.
Do not hesitate to contact the SearchStax Support Desk.