WebSphere Commerce search provides enhanced search functionality in starter stores by enabling enriched search engine capabilities such as automatic search term suggestions and spelling correction, while influencing store search results by using search term associations, and search-based merchandising rules.
Starting from Feature Pack 7, search server is a new WebSphere Application Server runtime instance with an embedded Solr runtime, which includes a published RESTful based API to interact with the WebSphere Commerce runtime instance. It de-couples the store pages into the presentation layer and business logic layer of search solution. With this approach, the search and browse-only traffic from the storefront can be offloaded away from the WebSphere Commerce server (transactional server), to the search server. The B2C store component pages use the RESTful API to retrieve necessary data from the Search Server instance and present it to an online store visitor. With this architecture, the search servers can be scaled separately and therefore the search and browse traffic can be handled independently, creating a flexible and scalable deployment model that can adjust to various storefront browsing traffic patterns at different times or shopping seasons.
A well designed cache is an important aspect of a well performing search solution in WebSphere Commerce. In this blog post, we will discuss the different types of caching that can be implemented pertaining to search.
The following diagram gives an overview of the caching configurations, triggers and invalidations with respect to the search solution of FEP7+.
There are multiple ways caching can be implemented in the WC and search servers. Typically, in Commerce server, we have:
1. JSP cache
2. Servlet cache (REST)
3. Command cache
4. Data cache
In the search server, we have:
1. Servlet cache (REST)
2. Data cache
3. Solr native cache
Let us discuss the cache configurations that are relevant for the search solution in FEP7+.
Search is used in the storefront in multiple places, mainly for category navigation, faceted navigation, keyword search and auto-suggest.
In keyword search and faceted navigation, there is a lower possibility of reuse of cache entries since there can be a large number of possible keywords and facet selections. Hence, the general recommendation is to not cache full page responses when keyword search or faceted navigation is used. In this case, caching at a lower level can provide a better cache hit ratio. For example, instead of caching the entire search results page, it makes sense to cache the individual product thumbnails which can be reused across different facet selections and search results.
On the other hand, the default version of category navigation pages (that is, without facet selections) can be full page cached. As mentioned above, for facet selections, it is beneficial to cache the individual product thumbnails as fragments. This would have the thumbnails cached for reuse across transactions but when the category page is repeatedly hit, the page would render without having to fetch/read all the individual product entries again.
As discussed earlier, with FEP7+, there is a separation between WC server and search server. The catalog pages, for example, category and product pages have REST calls which hit the search server directly. In this scenario, there can be two possible options for caching category navigation pages:
1) If WC JSPs are being used for rendering the UI then full page and fragment caching can be used as discussed above.
2) If a different technology is used as the front-end (for example, a content management system) and WC is used only as the back-end, then it is a common practice to use the REST API provided by WC for the business logic. In this case, the response of the REST calls can be cached in the search server (discussed in next point). This keeps the separation of browse and transactional traffic intact and as a result one can fully benefit from the ability to scale up search/browse traffic separately.
When using JSP caching, there are well documented invalidation techniques which can be implemented. Details can be found in IBM Knowledge Center:
REST services use both server-side caching and client-side caching. Server-side caching is achieved using dynacache, and client-side caching is achieved using cache directives in the response header.
The topic of REST caching is well documented, so I will not go into detail and instead just provide resources that can be useful for understanding how REST caching works. This topic in IBM Knowledge Center provides information about REST caching strategies.
To see an example of how to cache a REST request, you can refer to this blog post by Marco Fabbri.
From FEP7+, the search infrastructure can be deployed in a separated WAS cluster and then the dynacache service can be enabled on every cluster member the same way you do on Commerce servers. The response of the search REST calls can be cached using dynacache on the search server itself. This is an excellent blog post by Marco Fabbri that describes how to do so.
The default invalidation technique used on the search server is different from the WC server. Since there is no scheduler running on the search server, there is no DynaCacheInvalidation job that runs in the background to perform invalidations. The invalidation on the search server is managed by the cache manager instead. The search server periodically checks for pending invalidations (pending invalidation events in CACHEIVL table) before executing each request. What this means is that each search server instance is responsible for invalidation of its own (local) cache instances.
WebSphere Commerce contains code to use the WebSphere Dynamic Cache facility to perform more caching of database query results. This additional caching code is referred to as the WC data cache. Similar to this, there exists a data cache on the search server that is used for storing internal runtime properties that are used by certain search features to improve overall performance. These data object caches are configured to use DistributedMap object caches.
This Knowledge Center link provides a list of search data caches.
As with the base cache, the invalidations in the search data cache are managed by the cache manager on the search server. This blog entry by Andres Voldman can be referred to for more details about the search data cache configuration.
Solr native cache
To obtain maximum query performance, Solr stores several different pieces of information using in-memory caches. Result sets, filters and document fields are all cached so that subsequent, similar searches can be handled quickly. It is important to understand what they do and to tune them to suit the actual environment and search traffic.
You can refer to Apache Solr documentation for more information about Solr native cache.
There are multiple ways caching can be implemented in the WC and search servers. In this blog post, we discussed the cache configurations that are relevant for the search solution that uses the new search architecture introduced in Feature Pack 7.