Marketing cache design considerations

For more information about improving marketing performance with caching, see Improving marketing performance with caching.

Marketing business object cache (DM_Cache)

As another best practice, ensure that your site is updated to WebSphere Commerce Version 7 Fix Pack 2. With this fix pack, this cache can offload entries to disk to reclaim memory and improve performance. This cache is not capable of offloading entries to disk if WebSphere Commerce Fix Pack 2 is not installed.

Marketing user behavior cache (DM_UserCache)

DM_UserCache caches the current user behavior information for shoppers. This information is a cached version of the online behavior for shoppers that is recorded in the database. The recorded online behavior includes experiment paths, categories that are browsed, products that are browsed, search terms that are used, URLs matched, and non-repeatable activities. As a best practice for your store, assess the required size of this cache for your site and if needed, change the cache size. If your store encounters high volumes of traffic, increase the size of the cache. The default size of this cache is 10000 entries. For more information about caching user behavior, see the MarketingUserCache section in Marketing business object cache overview.

As another best practice, ensure that your WebSphere Commerce instance is updated to the Fix Pack 2 level. If WebSphere Commerce Version 7 Fix Pack 2 is installed, your site can enable this cache to offload entries to disk to reclaim memory and improve performance. This cache is not capable of offloading entries to disk if WebSphere Commerce Fix Pack 2 is not installed.

Marketing services - user behavior

Your site can use marketing services to temporarily store user behavior information updates. Any change to user behavior information is first recorded in memory and then periodically persisted in a batch to the database. You can modify the batch size by setting your changes in the marketing component configuration file, wc-admin-component.xml. For more information about recording data, see data recording: improving runtime performance. As a best practice, use the default settings, which include a default batch size of 200.

Marketing services - marketing statistics

Your site can also use marketing services to temporarily store marketing statistics. The gathered statistics are initially recorded in memory and then periodically persisted to the database with the SaveMarketingStatistics scheduled job. For more information about changing the frequency of the SaveMarketingStatistics scheduled job, see marketing statistics for Management Center. As a best practice, use the default settings for the SaveMarketingStatistics scheduled job.

If you are not using the marketing statistics, you can disable the collecting of these statistics. For more information, see Disabling marketing statistics

DynaCache marketing command cache

The DynaCache marketing command cache caches data that displays in e-Marketing Spots. This data includes catalog entries, categories, and store content information. The command cache cachespec can be used to cache queries that retrieve information from the database to display in the storefront e-Marketing Spots. As a best practice for your store, add the sample cachespec entries to the cachespec for your store. For more information about marketing command caching, see command caching for marketing.

Caching catalog hierarchy queries (WCMarketingDistributedMapCache)

Marketing (CampaignInitiativeCache) registry

The Marketing CampaingInitiativeCache registry keeps a mapping of an e-Marketing Spot name to the e-Marketing Spot primary key. This registry contains entries for e-Marketing Spots that are defined in the database and not defined in the database but that are still included on store pages. If your site fully caches e-Marketing Spot JSPs this registry provides no reuse. For this registry, each e-Marketing Spot is called only once and then the store JSP is cached. If your site fully caches e-Marketing Spot JSPs, you can disable this registry to prevent the memory usage of this registry for storing unnecessary cache entries.

Note: If you want to change the registry size or offload your entries to disk, you must upgrade your WebSphere Commerce instance level to WebSphere Commerce Version 7 Fix Pack 2. With this Fix Pack, entries are moved to the DM_Cache and you can offload these entries to disk. As a best practice for managing this registry, install WebSphere Commerce Version 7 Fix Pack 2. The transfer of entries to DM_Cache and the option of offloading entries to disk provides improved management options of this marketing registry.

Data propagation with the stagingprop utility

When the marketing data for your store is pushed to your production server, the marketing cached data must be cleared. Clearing this data is accomplished by clearing the CampaignInitiativeCache marketing registry. You can use an automated method of clearing this registry. You can enable database triggers on the production server to detect changes in the marketing data. When the triggers run, they insert an entry into the CACHEIVL database table that calls the DynacacheInvalidation scheduled job to clear the marketing registry. When the registry is cleared, the job then clears the marketing distributed maps. The job also issues an invalidation command for dialogMarketingJsp and dialogMarketingCommand. You can use these strings as dependency IDs so cached e-Marketing JSPs can be invalidated whenever the marketing information changes.

DynaCache marketing JSP fragment cache

There are some options to consider when you are designing your store pages in order to achieve optimal performance for your e-Marketing Spots. Querying the database to retrieve object information to load full objects for display in an e-Marketing Spot can impact resource usage. Your store e-Marketing Spots do not need to load full catalog entries, categories, or content from the database or command cache. You can configure your store e-Marketing Spots to return only ID information for catalog entries, categories, and store content. Returning only this information reduces the impact of queries for e-Marketing Spot evaluation. The Marketing Service can also cache this returned ID information so that it can be reused.

By returning only ID information, the client JSP needs to render only the catalog entry, category, or content with databeans or web services. The JSP fragment for the rendered catalog entry, category, or content is then cached for reuse. This process is the recommended technique for handling catalog entries, and is supported for categories and store content. If your store JSPs require more information to generate the HTML and javascript to display an object than is returning in the CatalogEntry SDO use this caching technique as a best practice for your store.

You can use this caching technique to return only the catalog entry ID and to cache the catalog entry display fragment to improve performance. With WebSphere Commerce Version 7 Fix Pack 1, the Madisons sample store uses this caching technique by default.

• The ScrollingProductsESpot.jsp file contains code that specifies that marketing services are to return product IDs. This configuration is enabled by setting the following parameter in the <getData> tag in the Get MarketingSpotData service call. The code for specifying the return of product IDs resembles the following code:

  <%-- do not retrieve the catalog entry SDO but obtain the catalog entry Id only --%>
  <wcf:param name="DM_ReturnCatalogEntryId" value="true" />

• The ScrollingProductsESpot.jsp file also contains code that specifies that the objects to be returned are CatalogEntryId objects instead of the CatalogEntry objects. The code to specify the return of the CatalogEntryId objects resembles the following code:

  <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'>

• For each product that displays in your store, your store is using a JSP fragment to display the product. These JSP fragments resemble the following code:

  <c:import url="${jspStoreDir}Snippets/Catalog/CatalogEntryDisplay/CatalogEntryThumbnailDisplay.jsp">

• You can cache the product display JSP fragment. To cache this fragment change the cache settings in the cachespec.xml file. This file is in samples\dynacache\Madisons directory. The cache entry settings for setting the product display JSP fragment to be cached resembles the following code:

  <cache-entry>
   <class>servlet</class>
  
   <name>/Madisons/Snippets/Catalog/CatalogEntryDisplay/CatalogEntryThumbnailDisplay.jsp</name>
   <property name="do-not-consume">true</property>
   <property name="save-attributes">false</property>
  
   <cache-id>
    <component id="emsName" type="parameter">
     <required>true</required>
    </component>
    <component id="catalogId" type="parameter">
     <required>true</required>
    </component>
    <component id="DC_storeId" type="attribute">
     <required>true</required>
    </component>
    <component id="DC_lang" type="attribute">
     <required>true</required>
    </component>
    <component id="DC_curr" type="attribute">
     <required>true</required>
    </component>
    <component id="DC_cont" type="attribute">
     <required>true</required>
    </component>
    <component id="DC_mg" type="attribute">
     <required>true</required>
    </component>
    <component id="intv_id" type="parameter">
     <required>true</required>
    </component>
    <component id="experimentId" type="parameter">
     <required>false</required>
    </component>
    <component id="testElementId" type="parameter">
     <required>false</required>
    </component>
    <component id="catEntryIdentifier" type="parameter">
     <required>true</required>
    </component>
   </cache-id>
   
   <dependency-id>storeId:productId
    <component id="storeId" type="parameter">
     <required>true</required>
    </component>
    <component id="catEntryIdentifier" type="parameter">
     <required>true</required>
    </component>
   </dependency-id>
   <dependency-id>productId
    <component id="catEntryIdentifier" type="parameter">
     <required>true</required>
    </component>  
   </dependency-id>
   <dependency-id>activityId
    <component id="intv_id" type="parameter">
     <required>true</required>
    </component>
   </dependency-id>
  </cache-entry>