In the second part of this series of posts on improving Sitecore indexing performance, I will cover a few more strategies that you can adopt. If you have not read the first part yet, you can read it here.
Consider applying DRY principle for indexes
Yes, “Don’t Repeat Yourself” !! If you have multiple indexes defined for the same database, avoid having the same item being added into multiple indexes. If not, any update to that item will result in the item being added to all the indexes, which in turn will slow down the operation that you are doing (authoring, package installation, publishing).
This can be applicable in case of a multi-site scenario wherein you may have an index per site that is configured to include only the items that belong to the site content node. At the same time, you may also have the default Sitecore indexes (sitecore_web_index, sitecore_master_index) which includes every content in Sitecore by default. Instead consider having mutually exclusive index crawler locations for all indexes of a Sitecore database in your environment.
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <contentSearch> <configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch"> <indexes> <!-- Default Sitecore index --> <index id="sitecore_web_index"> <!-- Rest of the index configuration is not provided here --> <locations hint="list:AddCrawler"> <crawler name="sharedcontent" type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch"> <Database>web</Database> <Root>/sitecore/content/Shared</Root> </crawler> </locations> </index> <!-- Site1's index --> <index id="sitecore_web_index_Site1"> <!-- Rest of the index configuration is not provided here --> <locations hint="list:AddCrawler"> <crawler name="site1content" type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch"> <Database>web</Database> <Root>/sitecore/content/Site1</Root> </crawler> </locations> </index> </indexes> </configuration> </contentSearch> </sitecore> </configuration>
Do note that the Search tab and Quick Search in Sitecore Content Editor uses the default Sitecore indexes. So if you adopted the approach described above, the search will not include results from site-specific content. This issue can be overcome by changing the context index based on the current context item in your Content Editor.
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <pipelines> <contentSearch.getContextIndex> <!-- Replace the below processor from Sitecore with your custom processor to fetch the context index --> <processor type="Sitecore.ContentSearch.Pipelines.GetContextIndex.FetchIndex, Sitecore.ContentSearch" /> </contentSearch.getContextIndex> </pipelines> </sitecore> </configuration>
Have indexes specific to a server role
Depending on the role of the server in your environment, have only the required indexes on those servers. While this is obvious, I have seen implementations wherein all indexes are maintained on all server nodes, which is a waste of resources on all machines. Below are some recommendations:
- CM servers – have only master index here
- CD servers – have only the index required for the publishing target on these servers (like web index)
- Dedicated publishing server – if this server is used for only publishing (no authoring), no indexes need to be on this machine
- Dedicated indexing server – if you have a dedicated server for indexing (like in case of Solr), you do not need to have indexes being built on any of the other servers in your environment
Optimize computed index implementation
Many a times, I have seen that custom computed index implementation impacts the indexing performance. Ensure that your computed index implementations are optimized. Avoid having expensive code like DB calls or API calls that can slow down your indexing. If there is a need for DB or API calls, consider pre-fetching this data and having it in some kind of in-memory cache, which can then be used by your computed indexes. Also handle any exceptions gracefully in your computed indexes.
A few additional approaches are covered in the concluding post of this series.