This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Performance Considerations When Migrating to REST-based Search
When moving from BOD-based search to REST-based search, you may be aware of the functional changes when using REST-based search and the new functionality available. However, due to the functional changes, there are performance considerations that must be accounted for to avoid serious performance issues when you are using REST-based search on your live environment. I will review topics that are a common source of performance issues on REST-based search if they are not taken into consideration during your migration/implementation.
REST Call Deadlocking
With BOD-based search, we used to perform most of the search query preprocessing and postprocessing on the Commerce server, and simply send the query itself to be processed on the Search server. With REST-based search, we will instead perform this processing on the Search server and send the results to the Commerce server. While we can perform most this processing on the Search server, there is some data that we need to callback to the Commerce server for. Specifically, there are two main callbacks out-of-the-box that can be sent during a search request:
Search Result Grouping
Search result grouping is new Search functionality available out-of-the-box starting in FEP7 for REST-based search. Search result grouping involves using Solr’s grouping query component to search on a product and it’s SKUs, returning the group representative (normally the product) if the search matches on either the product or it’s SKUs. Search result grouping can be an intensive operation to perform for a query, impacted significantly by the number of facets and results returned by the search. The more facets and results returned by the search, the larger the performance impact will be for using search result grouping.
If you plan to be using search result grouping, you should test the impact of search result grouping with your full data set to see the largest possible impact it can have on performance. We also have a Knowledge Center document for tuning product grouping that you can review for suggestions to reduce the performance impact that search result grouping has on your search query performance.
Extension indexes, like the Inventory and Price index, were initially introduced to simply filter against (like performing a Solr join). However, since being introduced, the extension indexes are being used for purposes like retrieving fields for display, searching, sorting, faceting, and much more. Using the extension indexes for purposes other than filtering results comes with a performance cost, which depends on the size of the result set as well as how intensive the operation is.
If you will be using the extension indexes for purposes other than filtering against it, you should test such queries with debugQuery=true to get performance information about the query and confirm the potential impact such queries will have. You can review my previous blog post on search query performance for information on reviewing the information provided by the debugQuery=true parameter. We also have a Knowledge Center document for search extension indexes, which highlights the impact and/or limitations for particular query parameters that reference the extension index.
Data Cache on Search Server
Since we are now performing most of the search scenario on the Search server, we will need to directly query the database for relevant search configuration information (ex. facetable attribute). As a result, we now include data cache on the Search server, which means that this data cache is going to need space on the Search server's heap.
Also, due to this additional work being performed on the Search server, the default configuration of 50 WebContainer threads for the Search server will likely need to be reduced.
If you have any questions about the topics discussed, feel free to provide a comment below.