3 ways to ensure your Solr-enabled Sitecore application runs smoothly
If you are upgrading to one of the latest versions of Sitecore (9.3 and up), it’s important to switch your default search engine to Solr if you haven’t already done so. Although Solr, Azure Search and Lucene have all been options since Sitecore 7, Lucene has been deprecated in the latest versions. Azure Search is going down the same path with the release of Sitecore 10 and will be removed in a future release.
Sitecore makes it relatively easy and compelling to switch to Solr; however, the application also needs to change to account for the differences in how Lucene and Solr work. This post will cover the application changes we recommend in order to maintain performance standards. If you are looking for further documentation on configuration differences and how Solr works, Sitecore has some detailed KB articles here:
The key difference between Solr and Lucene lies in how indexes are stored and accessed. Lucene indexes are stored in the local file system of each web server, with the application accessing the index files. Solr indexes, regardless of where they are stored, are accessed as a web service call by the application. If the application does not account for these differences, page load times could be adversely affected (which could later negatively impact SEO).
From our experience, here are a few things to consider to make sure your Solr-enabled Sitecore site runs smoothly:
Depending on your application functionality and how much content needs to be indexed and searched on, Solr indexes may require their own web servers. Your current CM/CD configuration will also play a role in this decision. Storing the indexes on one of your web servers should not be the default strategy without testing how your application responds under load.
The advantage of Solr is that you do not have to replicate the indexes locally in each web server. Multiple servers can share an index, which eliminates the issue of indexes being out of sync, a common challenge with Lucene. If storing the indexes locally on multiple web servers, indexing monitors should be put in place to keep the indexes in sync.
Solr searches per page
With Solr searches being web service calls, it is important to limit the number of calls made per page. This is especially critical if your application has pages that serve content from different parts of your website through search. For example, a product or service page that displays articles, people, related services, etc. could be making many calls to the search index. To improve performance, the application should combine as many of these calls as possible.
This consideration also extends to building components with Search. If multiple components performing search are put on a page, that decreases performance as well. Consider caching search results for high traffic pages to improve performance.
Limiting the number of calls on a page or caching search results is a great start, but it’s not enough. Each of these search calls should also bring back only the data that needs to be displayed on the search page. The pay load should be limited to only fields from Solr that are required to display the result compared to every field in that entity. The number of items that return should also be limited to what is displayed on the page. Any filtering should be done as part of search instead of post-processing after retrieving results.
Note that if you are moving from Azure Search, you probably had already accounted for the number of calls and pay load in your implementation, but it never hurts to double check.
Solr is an upgrade from Lucene or Azure Search in terms of functionality, ease in debugging and administering search. Leveraging the new search platform, and accounting for the above issues, will keep your Sitecore website performing well.
If you’re looking for additional guidance on Sitecore 10 and upgrading to this latest release, we can help. Contact us to learn more, and be sure to check out our Sitecore glossary, which breaks down all the popular Sitecore terms you should know.
As an Architect at One North, Erik provides technical assistance to new and ongoing client projects. He brings his wide range of technical expertise and experience to his role. Erik graduated from Purdue University with a degree in Computer Engineering.
Fun fact: My first name is John, however, I go by my middle name Erik.
Coach Erik: I coach the boys lacrosse team at Downers Grove South High School.
Vinu is the director of solutions architecture at One North, defining technical architecture for complex marketing/IT systems and products, acting as a technology consultant for clients and working with One North’s Experience Design team to define and implement solutions that will serve the client’s objectives now and in the future.
Favorite season: Summer – love the beach.
Superpower: Ability to breathe underwater