WebSphere Commerce search caching

WebSphere Commerce search uses fragment caching in the storefront.

Notes:

Search results from the search results page are not cached unless a category ID is associated with them. That is, search results with facets or search terms are not cached.
Cached search suggestions in starter stores are cached in JSP files using DynaCache. This caching uses the same rule as the cached header. That is, WebSphere Commerce caches the starter stores functionality for the auto-suggest menu for suggested categories, brands, site content, and search history.

For a fragment to be cacheable, it must be self-executable. Each dynamically included JSP file must contain its own <cache-entry> defined in the cachespec.xml file. This <cache-entry> is required to have the JSP file served up by the dynamic cache when it receives a request. Otherwise, each dynamically included JSP file is re-executed for each request. For example, if StoreCatalogDisplay.jsp dynamically includes CachedHeaderDisplay.jsp, CachedFooterDisplay.jsp and CachedStoreCatalogDisplay.jsp and you only set up a <cache-entry> for the CachedStoreCatalogDisplay.jsp. Then, when you request the StoreCatalogDisplay page, the CachedStoreCatalogDisplay.jsp, CachedHeaderDisplay.jsp, and CachedFooterDisplay.jsp files are executed if they are not cached.

Sample cache entries in starter stores

Here are examples of how WebSphere Commerce search defines the <cache-entry> for CachedSuggestions.jsp in the Madisons starter store and Elite starter store headers:

Madisons starter store

In the Madisons starter store, the <cache-entry> is defined as:


<cache-entry>
    <class>servlet</class>
    <name>/Madisons/include/styles/style1/CachedHeaderDisplay.jsp</name>
    <name>/Madisons/Snippets/Search/CachedSuggestions.jsp</name>
    <property name="do-not-consume">true</property>
    <property name="save-attributes">false</property>

    <cache-id>
      <component id="storeId" type="parameter">
        <required>true</required>
      </component>
      <component id="catalogId" type="parameter">
        <required>true</required>
      </component>
      <component id="DC_userType" type="attribute">
        <required>false</required>
        <not-value>-1002</not-value>
      </component>
      <component id="DC_lang" type="attribute">
        <required>true</required>
      </component>
    </cache-id>

    <!-- Dependency Ids -->
    <dependency-id>storeId
      <component id="storeId" type="parameter">
        <required>true</required>
      </component>
    </dependency-id>

    <dependency-id>StoreHeader:storeId
      <component id="storeId" type="parameter">
        <required>true</required>
      </component>
    </dependency-id>

    <dependency-id>catalogFilter:storeId
            <component id="storeId" type="parameter" multipleIDs="true">
                <required>true</required>
            </component>
       </dependency-id>


    <dependency-id>StoreHeader
    </dependency-id>
    <!-- Ends Dependency Ids -->
</cache-entry>

Elite starter store

In the Elite starter store, the <cache-entry> contains entitlement, and is defined as:


<cache-entry>
<class>servlet</class>
  <name>/Elite/include/styles/style1/CachedHeaderDisplay.jsp</name>
  <name>/Elite/Snippets/Search/CachedSuggestions.jsp</name>
  <property name="do-not-consume">true</property>
  <property name="save-attributes">false</property>

  <cache-id>
    <component id="storeId" type="parameter">
      <required>true</required>
    </component>
    <component id="catalogId" type="parameter">
      <required>true</required>
    </component>
    <component id="DC_userType" type="attribute">
      <required>false</required>
      <not-value>-1002</not-value>
    </component>
    <component id="DC_lang" type="attribute">
      <required>true</required>
    </component>
    <component id="DC_cont" type="attribute">
      <required>true</required>
    </component>
  </cache-id>

  <!-- Dependency Ids -->
  <dependency-id>storeId
    <component id="storeId" type="parameter">
      <required>true</required>
    </component>
  </dependency-id>

  <dependency-id>StoreHeader:storeId
    <component id="storeId" type="parameter">
      <required>true</required>
    </component>
  </dependency-id>

  <dependency-id>catalogFilter:storeId
            <component id="storeId" type="parameter" multipleIDs="true">
                <required>true</required>
            </component>
       </dependency-id>

  <dependency-id>StoreHeader
  </dependency-id>

  <dependency-id>storeId:contracts
    <component id="storeId" type="parameter">
      <required>true</required>
    </component>
    <component id="DC_cont" type="attribute" ignore-value="true">
      <required>true</required>
    </component>
  </dependency-id>

  <dependency-id>contracts
    <component id="DC_cont" type="attribute" ignore-value="true">
      <required>true</required>
    </component>
  </dependency-id>

  <dependency-id>contractId
    <component id="DC_cont" type="attribute" multipleIDs="true">
      <required>true</required>
    </component>
  </dependency-id>

  <!-- Ends Dependency Ids -->
</cache-entry>

Storefront caching

WebSphere Commerce caches the starter stores functionality for the auto-suggest menu for suggested categories, brands, site content, and search history:
Screen capture for cached auto-suggest menu

Screen capture for cached auto-suggest menu

Catalog filter caching

If your site uses catalog filters, ensure that catalog filter caching is enabled. For more information about enabling this type of caching, see setting up command caching for catalog filter.

Cache invalidation

When the search index is updated, the search related cache entries must be invalidated using the Dynacache API.

WebSphere Application Server dynamic caching provides the following APIs to support programmatic invalidation:

com.ibm.websphere.cache.invalidateById
com.ibm.websphere.cache.invalidateByTemplate
com.ibm.websphere.cache.clear

WebSphere Commerce also provides a DynaCacheInvalidation command, which is called by the scheduler periodically to process the records in the CACHEIVL table. It then calls the WebSphere Application Server dynamic cache invalidation APIs to invalidate the specified cache entries. By default, the schedule interval is every 10 minutes. For more information about this invalidation process, seeCache invalidation.

Caching considerations for WebSphere Commerce search

You can use fragment caching for WebSphere Commerce search results. However, you must practice caution to ensure that your caching strategy performs well. At a minimum, you must test your caching strategies before publishing [your store] to production.

In addition to using DynaCache in the WebSphere Commerce server and caching some of the relatively static search data, such as auto-suggested search entries, you can use the WebSphere Commerce search server to cache index data in memory. The size of the index cache pools must be configured based on the memory heap size that is allocated for the search server. For more information about configuring your WebSphere Commerce search, see WebSphere Commerce search performance tuning.