Mar. 17, 2020
admin
|
Solr is increasingly becoming a defacto search engine for Sitecore Implementations because of it’s performance, features, customizability and scalability. However, if Solr is not configured or used appropriately, applications sometimes notice performance problems.
Is the performance of your Solr search implementation sluggish and crawling along at a snail’s pace? Are you getting unexpected out-of-memory errors, suffering from spontaneous recovery mode issues or experiencing slow indexing performance?
Solr search configuration issues are complex and the prescriptions for fixing them are sometimes subtle. Through our deep experience with Solr configurations at SearchStax, we have learned that the solrconfig.xml settings are the root cause of many performance issues. The default values suggested by the system are sometimes poor choices and can lead to sustained high CPU usage or high JVM memory loading.
Too-frequent hard commits, with their massive load on CPU and disk I/O, are the worst offender. Fortunately, that problem and many others are easy to fix by following best practices to optimize or tune Solr search performance on Sitecore.
Follow these five SearchStax recommendations to optimize your solrconfig.xml settings and avoid the most-common Solr search performance issues with Sitecore. Lear more about each one of them below.
A “soft commit” achieves near-realtime (NRT) indexing by opening a new searcher after a specific time interval. It is faster and less expensive than a hard commit as it does not write the index to disk, or start a new transaction log. However, even though it is less expensive than a hard commit, it still utilizes resources and should be set for as long as it is reasonable for the application. We recommend setting this feature to two minutes or 120,000 milliseconds.
<autoSoftCommit>
<maxTime>120000</maxTime>
</autoSoftCommit>
A “hard commit” writes the in-memory index to the disk. It closes the current transaction log and opens a new one. It is best not to do this too frequently since it requires significant time. We recommend committing after at least five minutes.
If autoSoftCommit is enabled, which it is by default, that opens a new searcher on every soft commit. Since soft commits happen more frequently than hard ones, there is no need to have hard commits open searchers, too, and so we recommend setting the openSearcher flag as false.
<autoCommit> <maxTime>300000</maxTime> <openSearcher>false</openSearcher> </autoCommit>
As your collection sizes become large, Solr might not be able to create a snapshot of the index within 5 minutes. In those cases, for regular backups, you might have to consider increasing the commit settings higher – at 5 minutes for soft commits and 10 minutes for hard commits.
The query caches–filterCache, queryResultCache, and documentCache–store query results for faster retrieval on subsequent searches. We recommend setting the autowarmCount to zero for all of the cache settings.
<filterCache class="solr.FastLRUCache" size="512" initialSize="512" autowarmCount="0"/> <queryResultCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/> <documentCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/>
The queryResultCache has an additional optional setting, maxRamMB. This feature can be set to make sure that the cache does not consume too much memory, which can happen in cases where there are large stored fields returned as part of the query result.
We also recommend using the default value of 200 for queryResultMaxDocsCached.
<queryResultMaxDocsCached>200</queryResultMaxDocsCached>
The enableLazyFieldLoading setting allows Solr to load fields that are not directly requested later as needed. This can boost performance if most queries request only a small subset of fields.
We recommend leaving the enableLazyFieldLoading with the default value of true.
<enableLazyFieldLoading>true</enableLazyFieldLoading>
There can be cases where the same query is requested many times, but with different sort field / ordering. Setting useFilterForSortedQuery in these scenarios can give performance improvement as Solr would use a filter to satisfy the search and cache the results.
We recommend that useFilterForSortedQuery should be left as true.
<useFilterForSortedQuery>true</useFilterForSortedQuery>
If you want to learn more about best practices for tuning Solr performance, check out these additional resources:
Let us solve the technical aspects of your Solr for Sitecore infrastructure. With SearchStax Cloud, we focus on making sure you have a reliable, secure and compliant Solr setup. Create backups, disaster recovery and alert monitoring so you can focus on bigger initiatives. Request a demo to learn more.
Copyrights © SearchStax Inc.2014-2024. All Rights Reserved.
SearchStax Site Search solution is engineered to give marketers the agility they need to optimize site search outcomes. Get full visibility into search analytics and make real-time changes with one click.
close
SearchStax Managed Search service automates, manages and scales hosted Solr infrastructure in public or private clouds. Free up developers for value-added tasks and reduce costs with fewer incidents.
close
close